----- "Mathieu Bouchard" matju@artengine.ca a écrit :
On Mon, 16 May 2011, Matteo Sisti Sette wrote:
I often work with huge patches, and I'm noticing that loading the
same
patch in Linux takes at least 10 times (this is not an exageration)
the
time it takes in Windows, though the linux box I'm testing on has
better
hardware.
My experience is the other way around : opening one of GridFlow's help-patch was pretty fast using my old Linux laptop, but was quite slow using a newer Windows laptop. I made other tests and there seems to be a problem finding abstractions quickly. I didn't try changing the order of items in «Path...» but this could be making most of the difference.
Really? I always thought that slow gridflow's help patch opening was caused by graph on parent drawing, then caused by tcl-tk low speed.
I don't know about the problem you're experiencing. You'll have to investigate some more to figure out what may make a patch slow.
Btw, Lorenzo is joking.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 16 May 2011, Patrice Colet wrote:
Really? I always thought that slow gridflow's help patch opening was caused by graph on parent drawing, then caused by tcl-tk low speed.
With only one level of GOP, with rather few GUI items, it can't possibly happen. It has to be something else.
An average GFDP doc-item instantiates [doc_layout], [doc_editmode], [doc_iemfont], [doc_below], in addition to itself.
[doc_layout] itself instantiates [doc_bottom].
Some item have also a [doc_add] or [doc_make].
This means loading 6-7 files per doc item, except for comments (because I haven't replaced comments with funny-looking abstractions yet...;)
Back in the DOS days, if you looked in a folder that contained N files, you needed N system-calls (kernel) to get the whole list. I hope it isn't like that in Windows ??? ;)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC