Re: [Linuxsampler-devel] Profiling Linuxsampler

[Doug G. <dou...@gm...>]

Hi Christian,
Thank you for looking at this.

I commented out the code as suggested but this did not help other than
removing the Lambda function as a candidate cause.   BTW the sfz reload on
change behaviour is very useful indeed.

Attached are two profiles taken after making this change, exampl3 is about
15 seconds long spanning the onset and recovery of the fault event, the
second exampl4 captured during the failure event  itself (~8 seconds).

The most curious aspect of this issue for me is the way only one cpu core
hits 100% load during the event as if threads are not launching properly
beyond some threshold  and become locked preventing them being killed on
say a keyoff event.  Unfortunately this is just my hunch and so far I
haven't seen anything to support it withing the code.

Doug

On Sat, 9 Sept 2023 at 20:11, Christian Schoenebeck <
sch...@li...> wrote:

> On Wednesday, August 30, 2023 12:49:24 PM CEST Doug Gray wrote:
> > Christian,
> > Yes the output I posted  began  just before pressing sufficient keys to
> > trigger the failure event, ie laying my arm across the keys.  Capturing
> > only the key presses, the failure itself and subsequent recovery,
> > approximately 11 seconds in all.  Fortunately sysprof tool allowed
> > capturing an interval like this.
>
> OK, I was just confused because of the
>
>     sfz::InstrumentResourceManager::SfzResourceManager::Create()
>
> method call in your output, which should only be called while loading an
> instrument, not  during normal real-time playback.
>
> But I just realized that I misinterpreted the output: it is just there
> because
> Create() originally registered a Lambda Function by calling
> AddPeriodicJob():
>
>
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/engines/sfz/InstrumentResourceManager.cpp?view=markup&pathrev=4019#l173
>
> So it is that Lambda function registered by the AddPeriodicJob() call that
> is
> consuming those 10% CPU time.
>
> I am still not seeing any obvious cause for what you reported. But it is
> apparent that this registered Lambda function consumes more CPU time than
> it
> ought to be. So I would try testing by simpling commenting out that
> AddPeriodicJob() call and also by commenting out the following code block:
>
> 160                 // perform periodic, custom jobs on behalf of external
> components
> 161                 {
> 162                     LockGuard lock(periodicJobsMutex);
> 163                     for (ext_job_t job : periodicJobs) {
> 164                         job.fn();
> 165                     }
> 166                 }
>
>
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/engines/InstrumentManagerThread.cpp?view=markup&pathrev=4019#l160
>
> All it does is periodically checking if the SFZ file was externally
> modified,
> and if yes, it would automatically reload the SFZ file to adapt playback
> according to those external SFZ file changes.
>
> Tha feature is for people creating new SFZ files or modifying existing
> ones.
>
> /Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>