Hi,
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.
I know this is a very generic question but does perhaps anybody know where the bottleneck may be and why such a big difference between the two platforms (despite the popular belief that everything is usually faster in linux)?
thanks m.
Matteo Sisti Sette wrote:
Hi,
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.
It is well known that generally Windows performs much better than Linux, even on lower-end hardware. Additionally Pd although cross-platform is mainly developed for Windows and MACs... :)
By the way I experience exactly the opposite with my Granita patch.
I know this is a very generic question but does perhaps anybody know where the bottleneck may be and why such a big difference between the two platforms (despite the popular belief that everything is usually faster in linux)?
Seriously: A little more background information (possibly sharing one of the patches) would be helpful in order to help. I guess.
Lorenzo.
thanks m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
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
On 16/05/11 15:56, Mathieu Bouchard wrote:
there seems to be a problem finding abstractions quickly.
Probably bitrotted by now, and had issues/missing features even then: http://lists.puredata.info/pipermail/pd-list/2008-10/065307.html
Another thing to possibly check is whether dsp is on or off when you load patches, perhaps? I think Pd tries to turn it off before and restore the state after loading, though.
On 05/16/2011 05:09 PM, Claude Heiland-Allen wrote:
Another thing to possibly check is whether dsp is on or off when you load patches, perhaps?
Thank you, I already checked that (it's off), and the same happens with a big patch that has no dsp and which I run with -noaudio...
I have literally hundreds of instances of a few abstractions (in one case with gui and GOP, in another case with no gui at all), so I guess it is just the sum of the time it takes to create each instance; what surprises me the most is the big difference in performance between platforms, especially in favour of Windows.
On Mon, 2011-05-16 at 17:56 +0200, Matteo Sisti Sette wrote:
On 05/16/2011 05:09 PM, Claude Heiland-Allen wrote:
Another thing to possibly check is whether dsp is on or off when you load patches, perhaps?
Thank you, I already checked that (it's off), and the same happens with a big patch that has no dsp and which I run with -noaudio...
-noaudio does not mean 'do not do any DSP', it only means 'don't occupy any soundcard'. It's still possible to start DSP when -noaudio is used.
Roman
On 05/17/2011 08:54 AM, Roman Haefeli wrote:
-noaudio does not mean 'do not do any DSP', it only means 'don't occupy any soundcard'. It's still possible to start DSP when -noaudio is used.
Wow! I didn't know that (well I knew you could turn on the dsp checkbox but I thought it woudn't do any dsp).
Anyway in the slow loading happens with dsp turned off and with a patch that doesn't have any dsp objects.
By the way thank you for that, that sounds very interesting:
On 05/16/2011 05:09 PM, Claude Heiland-Allen wrote:
Probably bitrotted by now, and had issues/missing features even then: http://lists.puredata.info/pipermail/pd-list/2008-10/065307.html
Hi,
On Mon, May 16, 2011 at 12:36:15PM +0200, 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.
One thing that can slow down loading of patches is the searching for objectclasses in too many directories. At least we spotted this as a source for slow loading on iOS.
Maybe your Linux box has more entries in the search path settings than your Windows box? Check that and try to reduce the number of paths that are searched for objects.
Frank Barknecht Do You RjDj.me? _ ______footils.org__