--- On Wed, 12/15/10, Mathieu Bouchard <ma...@artengine.ca> wrote:
> From: Mathieu Bouchard <ma...@artengine.ca> > Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based > on 0.42.x branch) > To: "João Pais" <jmmmp...@googlemail.com> > Cc: pd-list@iem.at > Date: Wednesday, December 15, 2010, 1:11 AM > On Sun, 28 Nov 2010, João Pais > wrote: > > > I had a small look at [#many]. Do you think it would > be better to use C-coded objects instead for this kind of > "complex" gop abstractions? > > Well, you see, Pd *has* to grow more means to solve > problems using abstractions, so, I'm making the bet that I > can solve this problem with abstractions. I don't know > whether it'd really take less time with C code, and if I > did, I wouldn't end up with more means to solve problems > using abstractions. (I wrote small externals to support > [#many]). > > What makes you think that it would be better ? > > > I use lots of abstractions with gop (from my library, > specially [m-i] for midi input), and it seems to me that at > some point I have so many abstractions, that my patches take > longer to load. But I didn't do a real test to prove this. > > It seems that Pd on Windows takes several times more time > instantiating abstractions than on Linux and OSX, especially > with a full-blown path of 40 folders or so. This could be > mostly fixed if Claude's abstraction-cache had been included > in Pd, which can dramatically speed up abstraction-loading > on all platforms, but probably especially on Windows (but I > didn't check). Is this patch on the tracker? I can't find it. > > But this does not especially affect [#many], I'd guess. It > would be a lot worse if [#many]'s elements could be > abstractions, which is a planned feature. Then if you used a > gop-abstraction name as the first arg of [#many], you'd > trigger an insane number of lookups. > > This might be mitigated by specifying the absolute path to > the abstraction when instantiating. This wouldn't be a bad > idea to have an external that can lookup that, because as it > is, [#many foo 16 16] can't see foo.pd in the folder of the > patch that has [#many foo 16 16] in it, and that's more than > annoying, so, this issue has to be tackled anyway. > > But apart from that... can you find any abstraction > instances inside of [#many] ? I don't see any... so, it > shouldn't be much longer to load. > > GridFlow's three big abstractions are [doc_h] (9k), [#many] > (10k), and [#camera] (12.5k), and among them, [#many] is the > only to not load any other abstractions. > > > _______________________________________________________________________ > | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- > Villeray, Montréal, QC > > -----Inline Attachment Follows----- > > _______________________________________________ > Pd-list@iem.at > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list