| |||||||||||||
Real-life optimization workReal-life optimization workPosted Nov 2, 2005 23:31 UTC (Wed) by stef70 (guest, #14813)In reply to: Real-life optimization work by jwb Parent article: All hail the speed demons (O'Reillynet)
Apart from the fact that in the 'good old time', application had far less features, I also believe that they were not as fast as we usually remember.
For example, my first experience on UNIX was on some SUN X stations with a 486 processors. I was really impressed by the speed of those 'beast' and by they graphic capabilities. Everything was fast on those machines.
I was upgraded to a newer SUN using a sparc processor.
The configuration (hardware+software) was exactly the same as before but everything was slow. I could clearly see the window redrawing themselves.
About the clock applet: you should not trust an memory usage reported by the Linux kernel. In a desktop environment like Gnome, most of the memory is shared between applications and libraries. A more accurate way to evalute the memory footprint of the clock applet is to substract its SHARED memory from its RESIDENT memory. On my system (amd64) that gives 1.6MB.
Even 1.6MB is quite a lot for a simple clock.
A quick look in the memory map shows that about half of it is used by the clock applet itself (HEAP+STACK). The rest is used by the non-readonly segments (and so non-shared) of the shared libraries.
I think that the problem is the large number of shared library liked with each Gnome applications.
(Log in to post comments)
Real-life optimization work Posted Nov 3, 2005 0:41 UTC (Thu) by jwb (guest, #15467) [Link] To be perfectly fair, the GNOME calendar can read your appointments and whatnot out of Evolution's database, so that may explain the presence of S/MIME libraries and so forth. However, I can think of way, way more efficient methods of implementing that functionality, mainly involving a daemon (which evolution already has in surplus) and interprocess communication.
Real-life optimization work Posted Nov 3, 2005 10:08 UTC (Thu) by nix (subscriber, #2304) [Link] A quick look in the memory map shows that about half of it is used by the clock applet itself (HEAP+STACK). The rest is used by the non-readonly segments (and so non-shared) of the shared libraries./proc/*/smaps is useful, isn't it?
Real-life optimization work Posted Nov 3, 2005 19:05 UTC (Thu) by dann (guest, #11621) [Link] The crypto libraries are brought in because gnome-vfs is linked to them.libgnomeui links to gnome-vfs, so any GNOME application that links to libgnomeui will be linked to the crypto libraries. It would be better if gnome-vfs dlopened the crypto libraries on demand when they are used, that would avoid linking all the GNOME applications to the crypto libraries (and probably avoid loading them from disk on startup, as they probably are not used).
Real-life optimization work Posted Nov 4, 2005 13:26 UTC (Fri) by nix (subscriber, #2304) [Link] Shared libraries are paged in, not `loaded from disk'; the overhead of using extra shared libraries on a prelinked system is very low indeed. (dlopen()ing is rather a lot more expensive, as you can't prelink dlopen()ed libraries.)
Real-life optimization work Posted Nov 4, 2005 16:29 UTC (Fri) by dann (guest, #11621) [Link] "Paging in" does not make a big difference for small libraries during a cold startup, at least the symbol table and the _init need to be read from thedisk. Extra disk seeks are expensive.
Real-life optimization work Posted Nov 4, 2005 18:31 UTC (Fri) by oak (subscriber, #2786) [Link] Only if your mass storage is slow at seeking.
This is not the case if you use instead of hard disk for example Flash memory like is done on many embedded devices.
|
|||||||||||||