Hi
When I run pd the first time it takes a while to load, the second time it's much faster. I use a bash script to load my session (ardour, muse, pd + more) so if pd isn't running before muse, muse can't connect it's midi outs to pd's midi in.
I assume the load time is a matter of loading a binary, that's cached the second time. If so, where's the big binary? I tried running "cat /usr/local/bin/pd > /dev/null" in the beginning of my bash script, but that didn't seem to work.
If the above is a blind alley, whe could be done to speed up pd loadtime the first time?
NB: pd is version 0.40.3, and I'm running debian/linux...
Yes this is page/cache feature and seen with many apps. If you have a very frequently used app that you want to load fast each time then consider creating a RAM disk. Study Knoppix and Puredyne to see that in action. A start script to load Pd bins into RAM and then set the path to them. Useful for performance situations maybe.
On Wed, 03 Oct 2007 09:10:27 +0200 Atte André Jensen atte.jensen@gmail.com wrote:
Hi
When I run pd the first time it takes a while to load, the second time it's much faster. I use a bash script to load my session (ardour, muse, pd + more) so if pd isn't running before muse, muse can't connect it's midi outs to pd's midi in.
I assume the load time is a matter of loading a binary, that's cached the second time. If so, where's the big binary? I tried running "cat /usr/local/bin/pd > /dev/null" in the beginning of my bash script, but that didn't seem to work.
If the above is a blind alley, whe could be done to speed up pd loadtime the first time?
NB: pd is version 0.40.3, and I'm running debian/linux...
-- peace, love & harmony Atte
http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hmm, now has anyone noticed that Pd (first time after booting) starts up progressively more slowly over the months you own a linux machine? I'm suspicious that there's a correlation with how much software you have loaded on the machine. Maybe having lots of shared libraries and programs to use them makes dynamic linking slower (see, e.g., 'man ldconfig').
That's nothing but a guess.
cheers Miller
On Thu, Oct 04, 2007 at 12:53:46AM +0100, Andy Farnell wrote:
Yes this is page/cache feature and seen with many apps. If you have a very frequently used app that you want to load fast each time then consider creating a RAM disk. Study Knoppix and Puredyne to see that in action. A start script to load Pd bins into RAM and then set the path to them. Useful for performance situations maybe.
On Wed, 03 Oct 2007 09:10:27 +0200 Atte Andr? Jensen atte.jensen@gmail.com wrote:
Hi
When I run pd the first time it takes a while to load, the second time it's much faster. I use a bash script to load my session (ardour, muse, pd + more) so if pd isn't running before muse, muse can't connect it's midi outs to pd's midi in.
I assume the load time is a matter of loading a binary, that's cached the second time. If so, where's the big binary? I tried running "cat /usr/local/bin/pd > /dev/null" in the beginning of my bash script, but that didn't seem to work.
If the above is a blind alley, whe could be done to speed up pd loadtime the first time?
NB: pd is version 0.40.3, and I'm running debian/linux...
-- peace, love & harmony Atte
http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
one could avoid the dynamic linking by prelinking the binary ...
t
On Wed, 2007-10-03 at 09:15 -0700, Miller Puckette wrote:
Hmm, now has anyone noticed that Pd (first time after booting) starts up progressively more slowly over the months you own a linux machine? I'm suspicious that there's a correlation with how much software you have loaded on the machine. Maybe having lots of shared libraries and programs to use them makes dynamic linking slower (see, e.g., 'man ldconfig').
That's nothing but a guess.
cheers Miller
On Thu, Oct 04, 2007 at 12:53:46AM +0100, Andy Farnell wrote:
Yes this is page/cache feature and seen with many apps. If you have a very frequently used app that you want to load fast each time then consider creating a RAM disk. Study Knoppix and Puredyne to see that in action. A start script to load Pd bins into RAM and then set the path to them. Useful for performance situations maybe.
On Wed, 03 Oct 2007 09:10:27 +0200 Atte Andr? Jensen atte.jensen@gmail.com wrote:
Hi
When I run pd the first time it takes a while to load, the second time it's much faster. I use a bash script to load my session (ardour, muse, pd + more) so if pd isn't running before muse, muse can't connect it's midi outs to pd's midi in.
I assume the load time is a matter of loading a binary, that's cached the second time. If so, where's the big binary? I tried running "cat /usr/local/bin/pd > /dev/null" in the beginning of my bash script, but that didn't seem to work.
If the above is a blind alley, whe could be done to speed up pd loadtime the first time?
NB: pd is version 0.40.3, and I'm running debian/linux...
-- peace, love & harmony Atte
http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
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
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Linux is like a wigwam: no windows, no gates, apache inside, stable.
On Wed, Oct 03, 2007 at 09:15:06AM -0700, Miller Puckette wrote:
Hmm, now has anyone noticed that Pd (first time after booting) starts up progressively more slowly over the months you own a linux machine? I'm suspicious that there's a correlation with how much software you have loaded on the machine. Maybe having lots of shared libraries and programs to use them makes dynamic linking slower (see, e.g., 'man ldconfig').
That's nothing but a guess.
cheers Miller
i think this is not what is happening really..
i noticed a slowdown when i added a huge bunch of externals with different paths to them. so now i removed all and set the nessary once in one locations but with subdirectories (by name, as appears in the cvs). this seems to be fine ..
i think that ldconfig caches frequently used stuff in /etc/ld.conf.cache but still keeps only file descriptors in the memory ..
On Thu, Oct 04, 2007 at 12:53:46AM +0100, Andy Farnell wrote:
Yes this is page/cache feature and seen with many apps. If you have a very frequently used app that you want to load fast each time then consider creating a RAM disk. Study Knoppix and Puredyne to see that in action. A start script to load Pd bins into RAM and then set the path to them. Useful for performance situations maybe.
On Wed, 03 Oct 2007 09:10:27 +0200 Atte Andr? Jensen atte.jensen@gmail.com wrote:
Hi
When I run pd the first time it takes a while to load, the second time it's much faster. I use a bash script to load my session (ardour, muse, pd + more) so if pd isn't running before muse, muse can't connect it's midi outs to pd's midi in.
I assume the load time is a matter of loading a binary, that's cached the second time. If so, where's the big binary? I tried running "cat /usr/local/bin/pd > /dev/null" in the beginning of my bash script, but that didn't seem to work.
If the above is a blind alley, whe could be done to speed up pd loadtime the first time?
NB: pd is version 0.40.3, and I'm running debian/linux...
-- peace, love & harmony Atte
http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
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
I notice this not only on Pd but on most programs... gnome-terminal eventually starting taking so long to start up the first couple of times that I gave up and started with xterm, for example. Firefox takes a long time as well and I am using that every day...
km
On 10/4/07, ild0012@londonmet.ac.uk ild0012@londonmet.ac.uk wrote:
On Wed, Oct 03, 2007 at 09:15:06AM -0700, Miller Puckette wrote:
Hmm, now has anyone noticed that Pd (first time after booting) starts up progressively more slowly over the months you own a linux machine? I'm suspicious that there's a correlation with how much software you have loaded on the machine. Maybe having lots of shared libraries and
programs
to use them makes dynamic linking slower (see, e.g., 'man ldconfig').
That's nothing but a guess.
cheers Miller
i think this is not what is happening really..
i noticed a slowdown when i added a huge bunch of externals with different paths to them. so now i removed all and set the nessary once in one locations but with subdirectories (by name, as appears in the cvs). this seems to be fine ..
i think that ldconfig caches frequently used stuff in /etc/ld.conf.cache but still keeps only file descriptors in the memory ..
On Thu, Oct 04, 2007 at 12:53:46AM +0100, Andy Farnell wrote:
Yes this is page/cache feature and seen with many apps. If you have a very frequently used app that you want to load fast each time then consider creating a RAM disk. Study Knoppix and Puredyne to see that in action. A start script to load Pd bins into RAM and then set the path to them. Useful for performance situations maybe.
On Wed, 03 Oct 2007 09:10:27 +0200 Atte Andr? Jensen atte.jensen@gmail.com wrote:
Hi
When I run pd the first time it takes a while to load, the second
time
it's much faster. I use a bash script to load my session (ardour,
muse,
pd + more) so if pd isn't running before muse, muse can't connect
it's
midi outs to pd's midi in.
I assume the load time is a matter of loading a binary, that's
cached
the second time. If so, where's the big binary? I tried running "cat /usr/local/bin/pd > /dev/null" in the beginning of my bash script,
but
that didn't seem to work.
If the above is a blind alley, whe could be done to speed up pd
loadtime
the first time?
NB: pd is version 0.40.3, and I'm running debian/linux...
-- peace, love & harmony Atte
http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Use the source
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 4 Oct 2007, Kevin McCoy wrote:
I notice this not only on Pd but on most programs... gnome-terminal eventually starting taking so long to start up the first couple of times that I gave up and started with xterm, for example. Firefox takes a long time as well and I am using that every day...
Last time that I was having huge slowdowns, I looked at "top" by CPU usage, and it was showing a program called "hal" sucking 100% cpu all of the time and keeping the cpu hot.
(without any special priorities, in that case, one other program trying to get 100% will only get 50%, because cpu is shared equally)
gnome-terminal is an utter waste of RAM, but most people have plenty of RAM to waste. "top" now says it has 100 megs virtual RAM of which 9 megs are shared RAM, so I might be led to think that it's really taking 91 megs, but that is false. Say that the process id is 5262; then open the pseudo-file /proc/5262/maps as plain text. I have:
08089000-090c3000 rw-p 08089000 00:00 0 [heap]
Which is the main chunk of process-specific memory. The size is not written but you may compute it like this using bash:
echo $(( 0x090c3000-0x08089000 ))
and then it says 17014784, which is about 16.2 megs of RAM, only. It's a lot more RAM than what the scrollback buffers would warrant (here it says 636k per tab and I have 7 tabs open) but it's not 91 megs.
In a more automated way:
cat /proc/5262/maps | ruby -ne 'a=split;b=a[0].split"-";c=b[1].hex-b[0].hex;puts"#{c} #{a[1]} #{a[5]}"' | sort -n
all on one line, sorts all RAM segments of a process per size, and it seems that it's counting 25 megs of RAM per Gnome process just for the icons, which is mapped read-only. Now, by default, read-only mapped files do not take any more RAM than what they take in the disk cache. This is a lot less cumbersome than a read-write segment, which is the kind of segment that has to be swapped out when you lack RAM.
In short, "top" is not making a good breakdown of RAM usage.
I'd like to hear more reasons why startup and general operation might be slow.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
I use fluxbox WM, no hassle, no fancy bollocks. It's just X with some coloured window bars and a program launcher menu.
The MS Windows philosophy seriously subverted peoples expectations and understanding of what an "Operating System" and "Desktop" are. MS Windows and its imitators are not *operating systems* they are background application suites that burn energy running pointless tat you don't really need. I don't want spinning windows and dancing monkeys, if I wanted that I'd take drugs.
On Thu, 4 Oct 2007 11:56:43 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
On Thu, 4 Oct 2007, Kevin McCoy wrote:
I notice this not only on Pd but on most programs... gnome-terminal eventually starting taking so long to start up the first couple of times that I gave up and started with xterm, for example. Firefox takes a long time as well and I am using that every day...
Last time that I was having huge slowdowns, I looked at "top" by CPU usage, and it was showing a program called "hal" sucking 100% cpu all of the time and keeping the cpu hot.
(without any special priorities, in that case, one other program trying to get 100% will only get 50%, because cpu is shared equally)
gnome-terminal is an utter waste of RAM, but most people have plenty of RAM to waste. "top" now says it has 100 megs virtual RAM of which 9 megs are shared RAM, so I might be led to think that it's really taking 91 megs, but that is false. Say that the process id is 5262; then open the pseudo-file /proc/5262/maps as plain text. I have:
08089000-090c3000 rw-p 08089000 00:00 0 [heap]
Which is the main chunk of process-specific memory. The size is not written but you may compute it like this using bash:
echo $(( 0x090c3000-0x08089000 ))
and then it says 17014784, which is about 16.2 megs of RAM, only. It's a lot more RAM than what the scrollback buffers would warrant (here it says 636k per tab and I have 7 tabs open) but it's not 91 megs.
In a more automated way:
cat /proc/5262/maps | ruby -ne 'a=split;b=a[0].split"-";c=b[1].hex-b[0].hex;puts"#{c} #{a[1]} #{a[5]}"' | sort -n
all on one line, sorts all RAM segments of a process per size, and it seems that it's counting 25 megs of RAM per Gnome process just for the icons, which is mapped read-only. Now, by default, read-only mapped files do not take any more RAM than what they take in the disk cache. This is a lot less cumbersome than a read-write segment, which is the kind of segment that has to be swapped out when you lack RAM.
In short, "top" is not making a good breakdown of RAM usage.
I'd like to hear more reasons why startup and general operation might be slow.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Andy Farnell -
Atte André Jensen -
ild0012＠londonmet.ac.uk -
Kevin McCoy -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann