Re: [PD] Abstraction load time
--- On Tue, 5/12/09, Roman Haefeli wrote: > From: Roman Haefeli > Subject: Re: [PD] Abstraction load time > To: jancs...@yahoo.com > Cc: pd-list@iem.at > Date: Tuesday, May 12, 2009, 11:53 PM > On Tue, 2009-05-12 at 14:31 -0700, Jonathan Wilkes wrote: > > > > > > > > --- On Tue, 5/12/09, Roman Haefeli > wrote: > > > > > From: Roman Haefeli > > > Subject: Re: [PD] Abstraction load time > > > To: "Jonathan Wilkes" > > > > Cc: pd-list@iem.at > > > Date: Tuesday, May 12, 2009, 9:39 PM > > > it behaves like the opposite on my machine. the > abstraction > > > based patch > > > measures 6ms and the one, that generates > everything from > > > scratch, > > > measures ~300ms. > > > > > > now, after claude's explanation, i think, i > know why > > > this is the case. i > > > don't have any pathes loaded at all in my > preferences. > > > i try to do > > > everything with [declare]s inside the patches. > thus pd > > > hasn't to search > > > a whole bunch of pathes, but only the ones that > are really > > > useful. > > > > > > roman > > > > > > > Hi Roman, > > Ok, after clearing out all the path and startup > info under the "file" menu, my load times for the > abstraction based patch have decreased by an order of > magnitude. But now I'm puzzled because my results are > the reverse of yours: test-abs.pd takes around 250ms and > test-sp.pd takes 6ms. > > > > Are there any other preferences you alter to > restrict the paths that are searched? > > hm.. probably due to different versions of pd on different > platforms? i > am on linux using pd-vanilla 0.42.5. I'm on winxp with 0.42.5. > > i am not totally sure, but after the second opening of the > patch, the > harddisk isn't accessed anymore, so i guess, the > patches and > abstractions are in the cache anyway. this makes me think, > that it is > not harddrive related. > > i also found, that your measuring method was bogus. the > loadbang inside > abstraction will be executed _before_ the loadbang of the > parent patch. > i changed the patch and the result of test_sp.pd is now > 1100ms. i > attached fixed versions of all patches and abstractions. Oh man, I screwed up big time! Not only was the measuring wrong, but I mistakenly set test-sp.pd to create 1000 object chains instead of 100 -- that's why you're seeing such a large loading time for it. Very sorry about that. Here's a (hopefully) error-free version of everything. I'll see if I can try these patches out on another machine to see if its my hardware, operating system, or both that's causing some of the slowness I get when loading the abstractions. Thanks for the help, Jonathan > > roman absloadtest.rar Description: application/rar ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction load time
--- On Tue, 5/12/09, Roman Haefeli wrote: > From: Roman Haefeli > Subject: Re: [PD] Abstraction load time > To: "Jonathan Wilkes" > Cc: pd-list@iem.at > Date: Tuesday, May 12, 2009, 9:39 PM > it behaves like the opposite on my machine. the abstraction > based patch > measures 6ms and the one, that generates everything from > scratch, > measures ~300ms. > > now, after claude's explanation, i think, i know why > this is the case. i > don't have any pathes loaded at all in my preferences. > i try to do > everything with [declare]s inside the patches. thus pd > hasn't to search > a whole bunch of pathes, but only the ones that are really > useful. > > roman > Hi Roman, Ok, after clearing out all the path and startup info under the "file" menu, my load times for the abstraction based patch have decreased by an order of magnitude. But now I'm puzzled because my results are the reverse of yours: test-abs.pd takes around 250ms and test-sp.pd takes 6ms. Are there any other preferences you alter to restrict the paths that are searched? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction load time
it behaves like the opposite on my machine. the abstraction based patch measures 6ms and the one, that generates everything from scratch, measures ~300ms. now, after claude's explanation, i think, i know why this is the case. i don't have any pathes loaded at all in my preferences. i try to do everything with [declare]s inside the patches. thus pd hasn't to search a whole bunch of pathes, but only the ones that are really useful. roman On Mon, 2009-05-11 at 19:49 -0700, Jonathan Wilkes wrote: > I've been doing a lot of dynamic patching and notice that using abstractions > slows down the process immensely. > Why is it that test-abs.pd is so much slower than test-sp.pd (which just > creates chains of internal objects in a subpatch)? > Is there any way this could be sped up in future versions of pd? I find > dynamic patching to be a powerful idiom when used with abstractions, but its > kind of clunky right now because of the lengthy creation time. > > Thanks, > Jonathan > > p.s. please excuse the trivial nature of the dsp, which is just there for the > sake of comparison > > > > ___ Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction load time
--- On Tue, 5/12/09, Claude Heiland-Allen wrote: > From: Claude Heiland-Allen > Subject: Re: [PD] Abstraction load time > To: "Jonathan Wilkes" > Cc: pd-list@iem.at > Date: Tuesday, May 12, 2009, 12:39 PM > Hi, > > Jonathan Wilkes wrote: > > I've been doing a lot of dynamic patching and > notice that using abstractions slows down the process > immensely. > > That's because Pd tries to load the abstraction from > everywhere in its -path (which can be a large number of > places), then parses the text and uses it to create obects - > all of this EVERY time it is instanced. > > > Why is it that test-abs.pd is so much slower than > test-sp.pd (which just creates chains of internal objects in > a subpatch)? > > Is there any way this could be sped up in future > versions of pd? I find dynamic patching to be a powerful > idiom when used with abstractions, but its kind of clunky > right now because of the lengthy creation time. > > A quick and dirty attempt at caching abstractions in > memory: > > http://lists.puredata.info/pipermail/pd-dev/2008-10/012334.html Ah, that answers my question. Thanks for the explanation and link. Does the solution you came up with affect the load time of abstractions that are created after the patch has already been loaded? > > Also, I haven't checked the patches you attached, I > hope you're turning dsp off before doing the dynamic > patching and turning it on again (if desired) afterwards, > otherwise the dsp graph is rebuilt after every object > instead of just once (as far as I understand it). Oops, I didn't turn dsp off. Checking it now, it does increase load time a bit, though not nearly as much as using an abstraction instead of a chain of internal objects. Thanks, Jonathan > > > Claude > -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstraction load time
Hi, Jonathan Wilkes wrote: I've been doing a lot of dynamic patching and notice that using abstractions slows down the process immensely. That's because Pd tries to load the abstraction from everywhere in its -path (which can be a large number of places), then parses the text and uses it to create obects - all of this EVERY time it is instanced. Why is it that test-abs.pd is so much slower than test-sp.pd (which just creates chains of internal objects in a subpatch)? Is there any way this could be sped up in future versions of pd? I find dynamic patching to be a powerful idiom when used with abstractions, but its kind of clunky right now because of the lengthy creation time. A quick and dirty attempt at caching abstractions in memory: http://lists.puredata.info/pipermail/pd-dev/2008-10/012334.html Also, I haven't checked the patches you attached, I hope you're turning dsp off before doing the dynamic patching and turning it on again (if desired) afterwards, otherwise the dsp graph is rebuilt after every object instead of just once (as far as I understand it). Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Abstraction load time
I've been doing a lot of dynamic patching and notice that using abstractions slows down the process immensely. Why is it that test-abs.pd is so much slower than test-sp.pd (which just creates chains of internal objects in a subpatch)? Is there any way this could be sped up in future versions of pd? I find dynamic patching to be a powerful idiom when used with abstractions, but its kind of clunky right now because of the lengthy creation time. Thanks, Jonathan p.s. please excuse the trivial nature of the dsp, which is just there for the sake of comparison oscbank2~.pd Description: application/puredata oscbank~.pd Description: application/puredata oscvoice~.pd Description: application/puredata test-abs.pd Description: application/puredata test-sp.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
