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 > >>> > >>> > >>>_______________________________________________ > >>>[email protected] mailing list > >>>UNSUBSCRIBE and account-management -> > >>>http://lists.puredata.info/listinfo/pd-list > >>_______________________________________________ > >>[email protected] mailing list > >>UNSUBSCRIBE and account-management -> > >>http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
