I devised a quick test of loading speed and did some quick
comparisons on my MacBook Pro 2.4GHz. (I am used to having one of
the slowest machines around, my old 800Mhz Powerbook, so I still have
to readjust my thinking). Here's my times:
14ms Pd-0.39.3-extended 6.5ms Pd-0.40-2 vanilla 16ms Pd-0.40.3-extended-20071111
So on the face of it, it looks like really large time differences.
Percentage-wise it is a large difference, but perceptually, waiting
7ms vs. 16ms for something to load is not at all meaningful. No
human could tell the difference in the experience unless you were
generating sounds and visuals based on the opening and closing of the
patch.
This is, of course, on a fast machine. 300ms vs 800ms would be a big
perceptual difference, basically it would be the feeling of opening
quick versus a wait.
I'd be interested to see how this fares on other machines and OSes.
I attached the patches
.hc
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
I devised a quick test of loading speed and did some quick comparisons on my MacBook Pro 2.4GHz. (I am used to having one of the slowest machines around, my old 800Mhz Powerbook, so I still have to readjust my thinking). Here's my times:
14ms Pd-0.39.3-extended 6.5ms Pd-0.40-2 vanilla 16ms Pd-0.40.3-extended-20071111
So on the face of it, it looks like really large time differences.
Percentage-wise it is a large difference, but perceptually, waiting 7ms vs. 16ms for something to load is not at all meaningful. No human could tell the difference in the experience unless you were generating sounds and visuals based on the opening and closing of the patch.This is, of course, on a fast machine. 300ms vs 800ms would be a big perceptual difference, basically it would be the feeling of opening quick versus a wait.
I'd be interested to see how this fares on other machines and OSes. I attached the patches
first time i opened the patch on pd-0.40-2(vanilla): 14-16ms (cannot remember) second time the file was already cached, which gives me a result of 4ms (pretty constant) REALTIME: 4.206 REALTIME: 4.152 REALTIME: 4.127 REALTIME: 3.909 REALTIME: 4.092 REALTIME: 4.225
with pd-0.41-CVS (vanilla) i get: REALTIME: 6.953 REALTIME: 4.308 REALTIME: 4.579 REALTIME: 4.206
btw, did you now that you can use the "." as the path for "pd open"? few people i know will have the patch downloaded to /Users/hans/desktop
fmga.dr IOhannes
IOhannes m zmoelnig wrote:
first time i opened the patch on pd-0.40-2(vanilla): 14-16ms (cannot remember) second time the file was already cached, which gives me a result of 4ms (pretty constant) REALTIME: 4.206 REALTIME: 4.152 REALTIME: 4.127 REALTIME: 3.909 REALTIME: 4.092 REALTIME: 4.225
with pd-0.41-CVS (vanilla) i get: REALTIME: 6.953 REALTIME: 4.308 REALTIME: 4.579 REALTIME: 4.206
oops, the number are all from this machine: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
uname -a: Linux ferrari 2.6.21-1-multimedia-486 #1 SMP PREEMPT RT Fri Jun 22 19:13:23 UTC 2007 i686 GNU/Linux
mfga.rsd IOhannes
On Nov 12, 2007, at 3:36 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I devised a quick test of loading speed and did some quick
comparisons on my MacBook Pro 2.4GHz. (I am used to having one of
the slowest machines around, my old 800Mhz Powerbook, so I still
have to readjust my thinking). Here's my times: 14ms Pd-0.39.3-extended 6.5ms Pd-0.40-2 vanilla 16ms Pd-0.40.3-extended-20071111 So on the face of it, it looks like really large time
differences. Percentage-wise it is a large difference, but
perceptually, waiting 7ms vs. 16ms for something to load is not at
all meaningful. No human could tell the difference in the
experience unless you were generating sounds and visuals based on
the opening and closing of the patch. This is, of course, on a fast machine. 300ms vs 800ms would be a
big perceptual difference, basically it would be the feeling of
opening quick versus a wait. I'd be interested to see how this fares on other machines and
OSes. I attached the patches
One more to add:
~21ms Pd-0.39-2 vanilla
The difference between 0.39.2 vanilla and extended is probably due to
the improvements in Tcl/Tk. vanilla uses 8.4.5, extended 8.4.14
+cvs. For Mac people, Daniel Steffen recently has done a lot of work
on making Tk run faster on Mac OS X in 8.5, so if anyone wants to
experiment, I think there could be some real improvements there.
Thanks all for the responses, I am also hoping to get some tests of
the most recent Pd-0.40.3-extended nightly builds that use polygons
instead of lines for the boxes. I am hoping to track down the
mentioned slowness.
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Mon, 2007-11-12 at 21:36 +0100, IOhannes m zmoelnig wrote:
btw, did you now that you can use the "." as the path for "pd open"?
wrong.
this won't work as well, unless you start pd from within speedtest/ . i am actually quite happy about this example, because it illustrates well, that 'open' relative to pd's startlocation doesn't usually make sense at all (as i explained in numberous other threads).
miller: if you read this, please consider changing the [; pd open patch.pd path( so, that 'path' is relative to 'patch.pd'. this could be done without breaking backwards compatibility by introducing a new argument:
[; pd patch.pd path 1(
as it was done for 'menuclose' message to canvas.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
On Mon, 2007-11-12 at 21:36 +0100, IOhannes m zmoelnig wrote:
btw, did you now that you can use the "." as the path for "pd open"?
wrong.
this won't work as well, unless you start pd from within speedtest/ . i am actually quite happy about this example, because it illustrates well, that 'open' relative to pd's startlocation doesn't usually make sense at all (as i explained in numberous other threads).
i am aware of that. but "." is _much_ more likely to be the path wherein the patch lies than /Users/hans/Desktop/
so for those who are able to run Pd from the commandline (which is practically everyone, though some might not know or find it inconvenient), the "." will eventually work. the others will have to change the "." to there favourite path.
otoh, almost everybody will have to change the "/Users/hans/Desktop/" to their favourite path.
so i think, all in all the "." is a more user friendly thing.
miller: if you read this, please consider changing the [; pd open patch.pd path( so, that 'path' is relative to 'patch.pd'. this could be done without breaking backwards compatibility by introducing a new argument:
i think it wouldn't even break backwards compatibility if it was the default behaviour.
nfg.drs IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
so for those who are able to run Pd from the commandline (which is practically everyone, though some might not know or find it inconvenient), the "." will eventually work. the others will have to change the "." to there favourite path.
An alternative might be a additional setup step involving openpanel and writing the filename with its full local path to a message box.
Ciao
Frank Barknecht _ ______footils.org__
I got:
REALTIME: 73.6744 REALTIME: 22.4142 REALTIME: 21.4316 REALTIME: 22.3956
on four successive tries with Pd version 0.40.3-extended-20070905 on WinXP with dual Pentium 4 2.4GHz. I guess the first time loaded it into the disk cache or something like that. Anyway it seems like the other cpu is just for decoration.
Martin
From: Hans-Christoph Steiner hans@eds.org To: PD list pd-list@iem.at Subject: [PD] GUI speed test Date: Mon, 12 Nov 2007 15:01:03 -0500
I devised a quick test of loading speed and did some quick comparisons on my MacBook Pro 2.4GHz. (I am used to having one of the slowest machines around, my old 800Mhz Powerbook, so I still have to readjust my thinking). Here's my times:
14ms Pd-0.39.3-extended 6.5ms Pd-0.40-2 vanilla 16ms Pd-0.40.3-extended-20071111
So on the face of it, it looks like really large time differences.
Percentage-wise it is a large difference, but perceptually, waiting 7ms vs. 16ms for something to load is not at all meaningful. No human could tell the difference in the experience unless you were generating sounds and visuals based on the opening and closing of the patch.This is, of course, on a fast machine. 300ms vs 800ms would be a big
perceptual difference, basically it would be the feeling of opening quick versus a wait.I'd be interested to see how this fares on other machines and OSes. I attached the patches
<< speedtest.zip >>
.hc
Access to computers should be unlimited and total. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Steffen Juul wrote:
On 12/11/2007, at 21.43, Martin Peach wrote:
I guess the first time loaded it into the disk cache or something like that.
Is it relevant if Pd is closed in between?
Closing pd in between I get: REALTIME: 18.1368 REALTIME: 18.0402 REALTIME: 20.584 REALTIME: 18.0991 REALTIME: 17.8346
Martin
On Mon, 2007-11-12 at 15:01 -0500, Hans-Christoph Steiner wrote:
I devised a quick test of loading speed and did some quick
comparisons on my MacBook Pro 2.4GHz. (I am used to having one of
the slowest machines around, my old 800Mhz Powerbook, so I still have
to readjust my thinking). Here's my times:14ms Pd-0.39.3-extended 6.5ms Pd-0.40-2 vanilla 16ms Pd-0.40.3-extended-20071111
I get rather sporadic results with 0.39.3-extended:
5.019 8.171 7.637 10.828 4.997
Pd-0.40-2 vanilla is more consistent:
9.499 9.337 9.525 9.42 9.585
Ubuntu Gutsy on Dual-core 2.6GHz Macbook pro uname -r: 2.6.20-16-lowlatency
Jamie
Very similar machine to yours, Hans, except a little slower (MBPro 2 GHz. OS X 10.4.10)
19 ms. -- 0.49.3-extended-20071108 19 ms. -- 0.40.3-extended-20071011 17 ms. -- 0.39.3-extended
I'm curious what effect the dual-core is having on this, too. I thought I had chud loaded (Apple xcode tool to switch off a core), but I don't, and can't find the damn xcode tools disk. If I do, I'll post results w/ one core.
Phil
Hans-Christoph Steiner wrote:
I devised a quick test of loading speed and did some quick comparisons on my MacBook Pro 2.4GHz. (I am used to having one of the slowest machines around, my old 800Mhz Powerbook, so I still have to readjust my thinking). Here's my times:
14ms Pd-0.39.3-extended 6.5ms Pd-0.40-2 vanilla 16ms Pd-0.40.3-extended-20071111
So on the face of it, it looks like really large time differences.
Percentage-wise it is a large difference, but perceptually, waiting 7ms vs. 16ms for something to load is not at all meaningful. No human could tell the difference in the experience unless you were generating sounds and visuals based on the opening and closing of the patch.This is, of course, on a fast machine. 300ms vs 800ms would be a big perceptual difference, basically it would be the feeling of opening quick versus a wait.
I'd be interested to see how this fares on other machines and OSes. I attached the patches
.hc
Access to computers should be unlimited and total. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hans-Christoph Steiner wrote:
I'd be interested to see how this fares on other machines and OSes. I attached the patches
AMD Duron 1.3 GHz, Pd-0.39.3-extended-debian-stable-i386.deb
uname -a: Linux minerva 2.6.22.10-k7-custom #1 SMP PREEMPT Wed Oct 31 16:02:02 CET 2007 i686 GNU/Linux
Load times:
16.238 13.701 14.87 15.613
cu Thomas
"Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/
On Mon, 2007-11-12 at 15:01 -0500, Hans-Christoph Steiner wrote:
I devised a quick test of loading speed and did some quick
comparisons on my MacBook Pro 2.4GHz. (I am used to having one of
the slowest machines around, my old 800Mhz Powerbook, so I still have
to readjust my thinking). Here's my times:14ms Pd-0.39.3-extended 6.5ms Pd-0.40-2 vanilla 16ms Pd-0.40.3-extended-20071111
wow, you guys seem to have all very decent machines. i did only perform tests with pd-vanilla 0.40.2:
REALTIME: 24.534 REALTIME: 21.781 REALTIME: 7.182 REALTIME: 7.289 REALTIME: 7.372
(somehow it needed twice, until the patch was cached)
ubuntu dapper CPU: Intel(R) Pentium(R) M processor 1.70GHz (Family: 6, Model: 13, Stepping: 6)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Slower machine
Linux 2.6.8-2-386 Maxtor IDE 533MHz VIA Eden Vanilla 0.39.2
56.033 52.55 53.1 53.007 51.39 50.02
Faster machine
Linux 2.6.23-386 1.0GHz VIA Nehemia Seagate IDE Extended 0.40.3
30.30 22.09 22.26 23.15 24.001 23.0
On Mon, 12 Nov 2007 15:01:03 -0500 Hans-Christoph Steiner hans@eds.org wrote:
I devised a quick test of loading speed and did some quick
comparisons on my MacBook Pro 2.4GHz. (I am used to having one of
the slowest machines around, my old 800Mhz Powerbook, so I still have
to readjust my thinking). Here's my times:14ms Pd-0.39.3-extended 6.5ms Pd-0.40-2 vanilla 16ms Pd-0.40.3-extended-20071111
So on the face of it, it looks like really large time differences.
Percentage-wise it is a large difference, but perceptually, waiting
7ms vs. 16ms for something to load is not at all meaningful. No
human could tell the difference in the experience unless you were
generating sounds and visuals based on the opening and closing of the
patch.This is, of course, on a fast machine. 300ms vs 800ms would be a big
perceptual difference, basically it would be the feeling of opening
quick versus a wait.I'd be interested to see how this fares on other machines and OSes.
I attached the patches
-
Andy Farnell -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock -
Martin Peach -
Phil Stone -
Roman Haefeli -
Steffen Juul -
Thomas Mayer