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