[PD] How to reduce CPU use on unused subpatches-abstracts?

[Miller Puckette]

Oops, sorry - I think I'm leading you astray - it might take a long
time to figure out how to patch sources adn recompile Pd if you aren't
already habituated to compiling software.

Anyway, I don't really know that it's gensym() that's taking the 6%
of your processor - that's just a guess.  So I'm not sure what to try
next...

Miller

On Wed, Aug 07, 2013 at 05:23:16PM -0300, Mario Mey wrote:
> Oh... "*compile*"... I'm afraid of that word. Once (during some
> days), I tried to compile Pd... but with no good results.
> 
> I will try to download the source, look for a easy-to-compile
> tutorial... but, if it takes me so much time, I think I'll go on
> with the current version of PdExt (0.43.4). Maybe I will try it
> later... or later... or even more later.
> 
> To profile Pd, is there an option in my version, or I have to change
> code, like "#define PROFILE 1"?
> 
> Cheers.
> 
> 
> El 07/08/13 16:53, Miller Puckette escribió:
> >Here's an idea ... perhaps your patch is generating hundreds of thousands
> >of symbols to instantiate all the abstractions, and this sould be making
> >gensym() run slowly.  To test this possibility easily you could change
> >
> >#define HASHSIZE 1024
> >
> >to
> >
> >#define HASHSIZE 65536
> >
> >or so, recompile and see if that makes it run faster.
> >
> >(Of course, I don't know why gensym() would be getting called periodically
> >when Pd is idling; perhaps you could find that out by profiling Pd?)
> >
> >cheers
> >Miller
> >
> >On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote:
> >>Thanks all for responding. After doing some tests, with suggestion
> >>from mail-list and from (Maelstorm), I want to show you the current
> >>structure of the complete patch (the same I wrote in forum):
> >>
> >>/Main patch (meh_system.pd)//
> >>//• OSC messaging (for the tablet), input and output (EQ), BPM,
> >>metronome, Beats-to-rec, mode selector, etc.//
> >>//• FXs Console x2 (meh_console.pd)//
> >>//- - FXs & group selector, X-Y pad, Hold button, some signal and
> >>message redirection, etc. (subpatches)//
> >>//- - FXs groups x8 subpatches.//
> >>//- - - FXs abstracts x100 (fx-*.pd) ***//
> >>//• Sample Bank X8 (meh_bank.pd)//
> >>//- - Control subpatch [pd toggle-color-seteos]//
> >>//- - Sample - Resample subpatch [pd rec-sample-resample] ***//
> >>//- - Looping subpatch [pd rec-looping] ***//
> >>//- - Overdub subpatch [pd overdub] ***//
> >>//- - Playing subpatch [pd play]//
> >>//
> >>/The ones that have ***, have [switch~] inside. Using throw~/catch~
> >>and s~/r~, the audio signals (right/left, sample/resample) get
> >>inside and outside all that subpatches-abstracts.
> >>
> >>After adding switch~ inside them, *I got these RESULTS*:
> >>
> >>/•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on,
> >>although they are muted)
> >>/• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%*
> >>/• /DSP off: *6%*
> >>
> >>As you can see, from 47%, I achieve 20% less than before. I think it
> >>is very good! But, with DSP off, I have 6%.... and there's no
> >>message processing. Maelstorm told me that it is too much for doing
> >>nothing... and, we think that it is because of having all that
> >>abstracts there. If I delete them, I have 1-2%.
> >>
> >>The FX Console abstract (main patch has 2 of them) has all the FXs
> >>inside (100 items). Each FX has 4 to 8 abstracts inside (most of
> >>them are DIY2 effects, by Hardoff, but it also has a Panel abstract
> >>and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less.
> >>Even if they are swithched off... THEY ARE THERE. Maybe this
> >>increase the CPU to 6%?
> >>
> >>I repeat the WIP thread, where MEH-SYSTEM can be downloaded and
> >>tested: http://puredata.hurleur.com/viewtopic.php?pid=37430
> >>(it uses externals from PdExt and the zip includes ipoke2~.pd_linux
> >>for 64bits (my version of ipoke~, by Katja), but it's only for
> >>overdubbing)
> >>
> >>Thanks again.
> >>
> >>
> >>
> >>El 07/08/13 04:57, Roman Haefeli escribió:
> >>>On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
> >>>>On 08/07/13 03:15, Miller Puckette wrote:
> >>>>>Hmmm...  I was umnder the impression that, except for the overhead of block~
> >>>>>and switch~ objects, there would be no difference in DSP execution time
> >>>>>between a patch having lots of subpatches and one with the same amount of
> >>>>>computation all thrown in one window.  I haven't made any measurements but
> >>>>>theoreticall at least there shouldn't be any difference.
> >>>>i once did make measurements, and they showed that your assumption is
> >>>>correct.
> >>>>
> >>>>or at least, it showed that it *was* correct at that time. this was on a
> >>>>P2-400MHz in 1998 or so, where a 16 channel spatialization patch would
> >>>>eat about 95% of the CPU - regardless of whether you used a single huge
> >>>>patch or organized the code into subpatches/abstractions.
> >>>>
> >>>>eventually i went for using abstractions, and let the PC run at 95% for
> >>>>the 2 weeks show.
> >>>I once made some informal tests to measure the overhead of [switch~]. It
> >>>turned out it is quite big and if you're running hundreds or thousands
> >>>instances of [switch~] you probably gain nothing by turning DSP off in
> >>>subpatches. I don't know what the sweet spot is it seems using [switch~]
> >>>is only worth for subpatches with a minimum amount of (DSP) complexity.
> >>>
> >>>Roman
> >>>
> >>>
> >>>_______________________________________________
> >>>Pd-list at iem.at mailing list
> >>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>_______________________________________________
> >>Pd-list at iem.at mailing list
> >>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>