Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
This is a 6 month old thread, but today I came across an even older (15 year old, actually) book which is amusingly relevant to this thread - a thread which discussed the preposterous memory use of GNOME applications and applets. On Tue, Jan 16, 2007, Oded Arbel wrote about Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: And can something be done about it ?? 3310 odeda 16 0 181M 32696 4344 S 0.0 0.9 5:55.44 /usr/libexec/netspeed_applet2 --oaf-activate-iid= The network monitoring applet - shows a small box with the amount of bytes being passed through the interface at the moment. It also graphs network history for the last 5 minutes or so - still it uses 180MB, almost 20% of my total dynamic memory. I cringe to think about what people with 512MB memory do. The 15-year old book The UNIX Haters Handbook (now of print, but available freely online http://www.simson.net/ref/ugh.pdf) has a chapter on what it calls The X-Windows Disaster. Among other compliments to X, it says that X Windows is to memory as Ronald Raegan was to money. You thought that 32 MB of memory for a tiny applet was too much, but when that book was written, people were annoyed by much less: ... Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 xclock utility consumes 656K to run. And X's memory usage is increasing. (by the way, their count of 22 Commodore 64s is based on the incorrect assumption that the C64 had 64 K of usable RAM. In fact, of the addressable 64K, only 38 K were available to ordinary programs, so as many as 37 C64s are needed for olclock :-)) I don't share these author's dislike for the X Window System - in fact I think it is a fantastic invention that today is not understood enough and not used or developed to its full potential. I especially disagree with their dislike of the ICCCM (a technological disaster, a toxic waste dump of broken protocols). But I agree that software bloat is a terrible thing. Those who didn't cry out about the 1.4 MB clock applet of 1993, got a 32 MB clock applet in 2007... So down with software bloat! -- Nadav Har'El| Monday, Jun 4 2007, 18 Sivan 5767 [EMAIL PROTECTED] |- Phone +972-523-790466, ICQ 13349191 |Hi! I'm a signature virus! Copy me into http://nadav.harel.org.il |your signature to help me spread! = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Sunday 11 February 2007, Amit Aronovitch wrote: Eli Marmor wrote: The programs were also friendlier, because all the options in the (limited) UI/menus/etc were textual, in simple English, and not graphical icons that you must be a genious to guess what the programmer meant. If icons were really friendlier than text, it could be useful in other fields of life; For example, instead of speaking to each other, we could use pantomime. Fortunately, nobody is so cruel to force the people to communicate in pictures (except for UI experts who force the programmers to over-use graphics). Menus, like Icons, are just means to shorten the learning curve. Keyboard shortcuts rule ;-) While there's nothing wrong with short LC, it is orthogonal to program's productivity/usefulness. The problem is just another manifestation of consumption culture---nobody cares about long-term usefulness. Add more eye-candy, make it really easy to learn how to do one or two basic tasks (the stuff buyers normally think of when testing new software), and you get more market. By the time they get to their more complex needs, they'll have to buy a new version (and if they're already locked in, you don't care about their needs anyway). Nowadays, this has become an Ideology, well preached, e.g., by some of Joel Spolsky's much quoted articles (which are mostly true and clever advice---if you define good software as software that makes lots of money, of course...) It would be useful if you would cite your sources, and give hyperlinks and quotes to the articles in question. I can think of two articles by Joel that contradict what you implied: * http://www.joelonsoftware.com/articles/fog20.html * http://www.joelonsoftware.com/articles/fog17.html Also see: * http://www.joelonsoftware.com/items/2006/12/09.html -- If you can point to a place where Spolsky advocated this strategy, I would be grateful. In regards to icons, I believe they are useful instead of text because once youg get used to them you can locate them more easily based on their pictures. And in most modern GUIs all icons have tooltips to indicate their command, so it's not that bad. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Chuck Norris wrote a complete Perl 6 implementation in a day but then destroyed all evidence with his bare hands, so no one will know his secrets. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Friday, 9 בFebruary 2007 23:55, Nadav Har'El wrote: Like Chinese idiograms, if you have a 100 different actions in a toolbar you need to remember the 100 different pictures for them; These pictures are rarely self-explanatory, and when you need a specific one it takes you a long time to find the correct one. ... When Windows is installed, and there are just 5 icons there, it may (almost) make sense. I think you've hit the point. There were plenty of research (don't have a handy reference) that an average human (what's that?) can easily recognize 5-7 symbols in a flash. E.g: if you show someone a slide for a split second she would easily remember 5-7 objects on the slide. So icons are *excellent* for a small groups of objects, while representing large group of objects as icons just creates a lot of visual noise where only few icons which are very familiar and have a good contrast can stand-out (Firfox, PDF, etc.) Also, taking your other observation about ideographic vs. alphabetic languages. If the number of icons is far less then the number of letters in a typical alphabetic language (say 10 instead of 24), than the icons are better (just like a single letter word are easier to spot than multi-letter words). -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 But it does move! -- Galileo Galilei = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Eli Marmor wrote: The programs were also friendlier, because all the options in the (limited) UI/menus/etc were textual, in simple English, and not graphical icons that you must be a genious to guess what the programmer meant. If icons were really friendlier than text, it could be useful in other fields of life; For example, instead of speaking to each other, we could use pantomime. Fortunately, nobody is so cruel to force the people to communicate in pictures (except for UI experts who force the programmers to over-use graphics). Menus, like Icons, are just means to shorten the learning curve. Keyboard shortcuts rule ;-) While there's nothing wrong with short LC, it is orthogonal to program's productivity/usefulness. The problem is just another manifestation of consumption culture---nobody cares about long-term usefulness. Add more eye-candy, make it really easy to learn how to do one or two basic tasks (the stuff buyers normally think of when testing new software), and you get more market. By the time they get to their more complex needs, they'll have to buy a new version (and if they're already locked in, you don't care about their needs anyway). Nowadays, this has become an Ideology, well preached, e.g., by some of Joel Spolsky's much quoted articles (which are mostly true and clever advice---if you define good software as software that makes lots of money, of course...) I have clear explanation for what has happened since then, but I don't want to enter flaming wars. I doubt you'd get more flames here for such explanation than e.g. for claiming to have one. But might be better to post somewhere else anyways, e.g. [EMAIL PROTECTED] (or better yet, give a link to a blog entry). Posted using a full-of-icons-and-eyecandy-outlook-lookalike thunderbirdM-leftM-dicedove on a bloated-and-footprint-iconed Gnome desktop. What can I say - they got me too :-) AA = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Amos Shapira wrote: Keep an eye for Andy S. Tannenbaum's keynote at LCA this morning on http://lca2007.linux.org.au/Programme#head-6af3ad9cefbbb05127e86c3d2f00c2542a1bb75e (I'm sure the slides/audio/video will show up later). He talks exactly about this - how his PDP-11 with 64kb RAM used to boot in 4 seconds while his top-of-the-line Xeon server takes two minutes to boot, or how a VAX shared among 80 users and with 1 Mb of ram gave good service to all of them. Maybe I'm looking young, but I'm old enough to have the (great) experience to administer (in my past as a child) such a PDP-11 (model 34 with 128KB and 12 terminals). Everything worked great and fast. And you never had to wait for the computer, even when there were 12 simultaneous users. Since that computer served a school, the total number of users was higher (about 60), and the operating system was not small, so we had to upgrade our 5MB RL01 disk to 10MB RL02 disk. The programs were tiny so their quality was near-perfect. And even in the rare case of a bug, it was a piece of cake to debug, not only because the programs were smaller and easier, but also because they were flowchart-based and not event-based (with a huge mainloop that serves everything, a model that is main responsible for the spaghetti look of today's code). The programs were also friendlier, because all the options in the (limited) UI/menus/etc were textual, in simple English, and not graphical icons that you must be a genious to guess what the programmer meant. If icons were really friendlier than text, it could be useful in other fields of life; For example, instead of speaking to each other, we could use pantomime. Fortunately, nobody is so cruel to force the people to communicate in pictures (except for UI experts who force the programmers to over-use graphics). I have clear explanation for what has happened since then, but I don't want to enter flaming wars. -- Eli Marmor Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On 10/02/07, Eli Marmor [EMAIL PROTECTED] wrote: Amos Shapira wrote: Keep an eye for Andy S. Tannenbaum's keynote at LCA this morning on http://lca2007.linux.org.au/Programme#head-6af3ad9cefbbb05127e86c3d2f00c2542a1bb75e (I'm sure the slides/audio/video will show up later). He talks exactly about this - how his PDP-11 with 64kb RAM used to boot in 4 seconds while his top-of-the-line Xeon server takes two minutes to boot, or how a VAX shared among 80 users and with 1 Mb of ram gave good service to all of them. Maybe I'm looking young, but I'm old enough to have the (great) experience to administer (in my past as a child) such a PDP-11 (model 34 with 128KB and 12 terminals). Everything worked great and fast. And you never had to wait for the computer, even when there were 12 simultaneous users. Since that computer served a school, the total number of users was higher (about 60), and the operating system was not small, so we had to upgrade our 5MB RL01 disk to 10MB RL02 disk. The programs were tiny so their quality was near-perfect. And even in the rare case of a bug, it was a piece of cake to debug, not only because the programs were smaller and easier, but also because they were flowchart-based and not event-based (with a huge mainloop that serves everything, a model that is main responsible for the spaghetti look of today's code). The programs were also friendlier, because all the options in the (limited) UI/menus/etc were textual, in simple English, and not graphical icons that you must be a genious to guess what the programmer meant. If icons were really friendlier than text, it could be useful in other fields of life; For example, instead of speaking to each other, we could use pantomime. Fortunately, nobody is so cruel to force the people to communicate in pictures (except for UI experts who force the programmers to over-use graphics). I have clear explanation for what has happened since then, but I don't want to enter flaming wars. Sharing your wish to avoid flame wars (I'm not even sure why you raised that issue), and with respect, I would like to offer a couple of points about your arguments: 1. Comparing single-user, text-only programs and mostly un-networked time-sharing systems of 70's/80's to the current software is like comparing apples to oranges. The PDP-11 system only had to deal with that much users who can connect to it over 9600 baud RS-232 and which have only local data to deal with, while today's desktops (trying to keep the comparision valid, so I'll leave servers out of this) have to deal with users who have multimedia and networked needs, multi-language (can you imagine anyone in your house besides you being able to use the affore-mentioned PDP-11 as they use today's systems? OR for that matter - could you do on that PDP-11 system the same things you yourself do with your home desktop today?). Therefore the software has a much more complex task to handle. Therefore it is excusable that the software will be much more complex. An analogy might be comparing Walmart (the world's largest retail store) to the local grocery store - the grocery store might be more efficient, but it might not be able to provide all the needs of its customers. There Although I stated above that there is a good excuse for today's software to be more complex, I'm NOT defending GNOME's current bloat. Maybe a good reference would be GNOME/KDE vs. Enlightenment ( http://lca2007.linux.org.au/talk/101). Just from reading his slides, it looks like he manages to demonstrate a comparable user interface to GNOME's/KDE's with a much lower CPU and memory signature (I'm aware that E by itself doesn't provide all the features that the full GNOME package provides, but in those that it does provide (terminal, sound, WM) it does it using much less resources). And this seems to be his main focus - EFFICIENT graphics user interface. 2. The issue of icons - I disagre that icons are stupid. Yes, there are many which you have to guess at but: a. I wouldn't want to imagine my toolbar (currently XFCE 4 panel) with all the tools on it being represented by text instead of simple symbols, same with OO and FF toolbar buttons. Maybe some programs took this a bit too far but in general it's a very effective way to help find the button you want and conserve screen real estate. b. Icons are used daily everywere, not just on computers - just take a walk down the street and see that almost none of traffic signs has text in them (and even those with numbers have different meaning for the numbers depending on color/shape of the sign). In Israel it might be even more relevant because there is a high percentage of immigrants who can't read Hebrew properly. In Australia, where there are many text-based signs, I heard about one suburb where Vietnamesse residents asked the council to put signs in Vietnamesse for the benfit of the residents who can't speak the local language - English. Traffic signs are not the only thing
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On 10/02/07, Nadav Har'El [EMAIL PROTECTED] wrote: this mess. Wouldn't it have been better to use a textual menu? Of course it would, which is why the Start menu was finally added to MS-Windows. Too bad people continue to (ab)use the desktop. I never use my Linux desktop to keep icons, at most I create short-cuts for the most useful programs on the toolbar. But yet even when I pop-up the menu and look for the program I want, my eye scans much faster for Iceweasel's or Skype's familiar icons than to the text next to them. Just speaking from personal experience, I'm the first to admin that I know zilch about GUI design... Cheers, --Amos
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On 17/01/07, Amos Shapira [EMAIL PROTECTED] wrote: On 17/01/07, Nadav Har'El [EMAIL PROTECTED] wrote: On Tue, Jan 16, 2007, Oded Arbel wrote about Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: I usually see a problem after about a week of usage - after a reboot it behaves itself for a few days. I rebooted this morning, and now Evo is down to 400MB. With the mad race to get better and better hardware, it seems that people forgot how to write efficient software. One of the lost arts is preventing memory leaks. Keep an eye for Andy S. Tannenbaum's keynote at LCA this morning on http://lca2007.linux.org.au/Programme#head-6af3ad9cefbbb05127e86c3d2f00c2542a1bb75e (I'm sure the slides/audio/video will show up later). He talks exactly about this - how his PDP-11 with 64kb RAM used to boot in 4 seconds while his top-of-the-line Xeon server takes two minutes to boot, or how a VAX shared among 80 users and with 1 Mb of ram gave good service to all of them. He quoted someone from Microsoft to the effect of Software gets slower faster than hardware gets faster Ah, and another good quote - Software is gas - it grows to use all of its container. (He then goes on to a different path - explaining why Minix 3's tiny amount of kernel-mode code is important in a world of bloated software). The video is now available in OGG Theora format at http://mirror.linux.org.au/pub/linux.conf.au/2007/video/wednesday/Wednesday_0900_Tanenbaum.ogg (from http://lca2007.linux.org.au/Programme). --Amos
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Memory-usage in a modern OS is complicated, as many people on this list have already shown. While most users will cry memory leak and give out incorrect observations (and power-users can often get very technical speaking about something they don't thoroughly understand), their complaints do reflect a problem. That's why, in the recent year, memory consumption and performance problems have generated a lot of developer interest in the GNOME circles, as you could see by following the Planet GNOME (http://planet.gnome.org). You can also check Federico Mena Quintero's blog ( http://primates.ximian.com/~federico/news.html) for some of his notes about performance work he's been doing, if you wish to get a (developer-oriented) picture of whatever causes those things. One popular memory bug is constants which are not placed in readonly-segments in shared libraries: this causes this memory to be spent for every process linking in this library. Here you might find some more info: http://live.gnome.org/MemoryReduction The recent Linux kernels (2.6.114) added 'smaps' per-process data [2] which allows you to find out how much RSS the shared libraries are using, and thus to subtract them from the process' own RSS (its' executable data + heap). Read more about it here: http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps.html Really, there are encouraging news on that front, but the general answer to Free Software woes remains: if you want to get something done, join the effort. On 1/16/07, Oded Arbel [EMAIL PROTECTED] wrote: And can something be done about it ??
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Hi, Gnome clock applet is not a clock, but a huge process with evolution data server and client code involved. You are talking about its menus. Take into account that these are evolution menus. If you click on the GNOME clock applet, calendar appears. If you double click on a day in the calendar, evolution appears. - Moshe Gorohovsky. Oded Arbel wrote: On Tue, 2007-01-16 at 22:40 +0200, Nadav Har'El wrote: Let's compare a few clock applications: app VIRTRES NOTE xdaliclock 3756796 oclock 36321540 xclock 85442976 kclock.kss 25840 8164 clock-applet (Gnome) 90212 11256 (only the applet process) clock_panelapplet (KDE) 33664 12028 (for kicker with only a clock applet) Hardly fair - Kicker does tons of stuff even when no applet is loaded - its the entire panel mechanism (including the main menu, or without ?). If you want to compare apples and apples, you should compare your KDE figure with the sum of gnome's clock applet and gnome-panel (entirely - everything that is painted on the gnome-panel is out-of-process). Trying to understand where Gnome's clock-applet's huge VIRT comes from, I discovered something very interesting. It start with just 28 MB of VIRT, but at the moment you right-click on the clock, and a menu pops up, it grows to, belive it or not - 90 MB. That's 60 MB to show a menu !? I diffed the /proc/../maps, and this is what the extra 60 MB contain: 0.5 MB of newly allocated memory, plus a lot of mapped files; One interesting mapped file is the HUGE /usr/share/icons/crystalsvg/icon-theme.cache, taking up 28 MB of mapped space! I'll check some of the other suspects to see whats in their mappings. Funny enough, gnome-system-monitor has a UI for /proc/../maps, which - if I'm reading it correctly - shows that Evolution with a relatively small VIRT of 500MB maps over 200MB of it as writable memory. Just as a comparison, that 200MB is almost twice as the entire VIRT size of KMail. -- Oded ::.. Learning is what most adults will do for a living in the 21st century. -- Perelman = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Moshe Gorohovsky A6 CC A7 E1 C2 BD 8C 1B 30 8E A4 C3 4C 09 88 47 Tk Open Systems Ltd. --- - tel: +972.2.679.5364, http://www.tkos.co.il - = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Sun, 2007-01-21 at 10:44 +0200, Moshe Gorohovsky wrote: Hi, Gnome clock applet is not a clock, but a huge process with evolution data server and client code involved. You are talking about its menus. Take into account that these are evolution menus. If you click on the GNOME clock applet, calendar appears. If you double click on a day in the calendar, evolution appears. The KDE clock applet is similar. evo-data-server is out-of-process, but the kde clock also has korganizer client code, and when you click on it you get a calendar as well. Still there's not much reason for the GNOME clock to be so much larger then the KDE clock applet. -- Oded ::.. I wish Lucas Co. would get the thing going a little faster. I can't really imagine waiting until 1997 to see all nine parts of the Star Wars series. -- Randal L. Schwartz (at 1982 on usenet) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
You are right, GNOME clock consumes too much memory for its tasks. Briefly checking clock.c (http://svn.gnome.org/viewcvs/gnome-panel/trunk/applets/clock/clock.c?rev=10182view=markup) I can not see a reason for this memory consumption. The calls to evolution code and the evolution data usage seems to be encapsulated by well-organized code. - Moshe Gorohovsky Oded Arbel wrote: On Sun, 2007-01-21 at 10:44 +0200, Moshe Gorohovsky wrote: Hi, Gnome clock applet is not a clock, but a huge process with evolution data server and client code involved. You are talking about its menus. Take into account that these are evolution menus. If you click on the GNOME clock applet, calendar appears. If you double click on a day in the calendar, evolution appears. The KDE clock applet is similar. evo-data-server is out-of-process, but the kde clock also has korganizer client code, and when you click on it you get a calendar as well. Still there's not much reason for the GNOME clock to be so much larger then the KDE clock applet. -- Oded ::.. I wish Lucas Co. would get the thing going a little faster. I can't really imagine waiting until 1997 to see all nine parts of the Star Wars series. -- Randal L. Schwartz (at 1982 on usenet) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Moshe Gorohovsky A6 CC A7 E1 C2 BD 8C 1B 30 8E A4 C3 4C 09 88 47 Tk Open Systems Ltd. --- - tel: +972.2.679.5364, http://www.tkos.co.il - = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On 16/01/07, Hetz Ben Hamo [EMAIL PROTECTED] wrote: Hello Oded, people... Few weeks ago, I worked temporarily at a small company, and they gave me a PC which was with Athlon XP (if I recall it was 1.6 Ghz or something) with 756MB RAM to work with. So, I installed CentOS 4.4, upgraded my KDE 3.5.5, and upgraded OpenOffice to the latest one, and used FireFox 2 for browsing. I started to work. I started to use OpenOffice to write a small spreadshot. BOY was it slow as hell! it was so slow that I was almost sure I had some Pentium 2 300Mhz processor. Switching apps (using ALT TAB) was a PITA. I have not been running many applications: Twinkle, Kopete, FireFox, KMail, OO, and Konsole. Nothing more. The machine was crawling. I took Office 2003 from the Windows team, installed Crossover 6 (the latest version finally solves the flickering flash bug), and started to use Office 2003. Finally I could write somthing without the machine being crawling, but opening few more tabs in FF 2, and the machine crawled again.. My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. I heard my advocates who recommend people to switch to Linux and use KDE or GNOME with 256MB RAM. To them I can say HA HA! go ahead, fire the latest GNOME and open 2-3 apps and give the machine a minute or so, it will be almost unresponsive. It's better in KDE but not by much. If someone wants something speedy, they should look at using FVWM, flux box or any other lite window manager and use some independent applications. I used FVWM with Kopete and KMAIL and Konqueror, and the results were pretty good on a 192MB machine. I tried to switch to GNOME (yes, stupid decision) and I had to reset the machine in order to get my control back. Today, everyone is laughing/amazed by the hardware requirement of Windows VISTA (specially with Aero Glass interface). Well, my friends, at this pace, GNOME (and maybe even KDE) is going at this way, with all the latest GLX eye-candy, and the hefty memory requirements. I do not know the future, but I do remember KDE usage only few years ago with a Pentium 4 1.7Ghz, 512MB RAM, and it was very usable and enjoyable. Thanks, Hetz KDE is still very usable, if you use it. Instead of FIrefox, use Konqueror. Instead of OpenOffice, use KOffice. Instead of Thunderbird, use Kmail. You'll find that it'll run just fine on a machine with 128MB RAM, even though the KDE developers recommend 192MB. And don't runn Apache, Bind, SSH, or other daemeons in the background if you don't need them. Dotan Cohen http://lyricslist.com/lyrics/lyrics/149/377/nine_inch_nails/the_fragile_right.html http://fedorafaqs.org = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 22:40 +0200, Nadav Har'El wrote: Let's compare a few clock applications: app VIRTRES NOTE xdaliclock3756796 oclock36321540 xclock85442976 kclock.kss25840 8164 clock-applet (Gnome) 90212 11256 (only the applet process) clock_panelapplet (KDE) 33664 12028 (for kicker with only a clock applet) Hardly fair - Kicker does tons of stuff even when no applet is loaded - its the entire panel mechanism (including the main menu, or without ?). If you want to compare apples and apples, you should compare your KDE figure with the sum of gnome's clock applet and gnome-panel (entirely - everything that is painted on the gnome-panel is out-of-process). Trying to understand where Gnome's clock-applet's huge VIRT comes from, I discovered something very interesting. It start with just 28 MB of VIRT, but at the moment you right-click on the clock, and a menu pops up, it grows to, belive it or not - 90 MB. That's 60 MB to show a menu !? I diffed the /proc/../maps, and this is what the extra 60 MB contain: 0.5 MB of newly allocated memory, plus a lot of mapped files; One interesting mapped file is the HUGE /usr/share/icons/crystalsvg/icon-theme.cache, taking up 28 MB of mapped space! I'll check some of the other suspects to see whats in their mappings. Funny enough, gnome-system-monitor has a UI for /proc/../maps, which - if I'm reading it correctly - shows that Evolution with a relatively small VIRT of 500MB maps over 200MB of it as writable memory. Just as a comparison, that 200MB is almost twice as the entire VIRT size of KMail. -- Oded ::.. Learning is what most adults will do for a living in the 21st century. -- Perelman = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On 17/01/07, Nadav Har'El [EMAIL PROTECTED] wrote: On Tue, Jan 16, 2007, Oded Arbel wrote about Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: I usually see a problem after about a week of usage - after a reboot it behaves itself for a few days. I rebooted this morning, and now Evo is down to 400MB. With the mad race to get better and better hardware, it seems that people forgot how to write efficient software. One of the lost arts is preventing memory leaks. Keep an eye for Andy S. Tannenbaum's keynote at LCA this morning on http://lca2007.linux.org.au/Programme#head-6af3ad9cefbbb05127e86c3d2f00c2542a1bb75e (I'm sure the slides/audio/video will show up later). He talks exactly about this - how his PDP-11 with 64kb RAM used to boot in 4 seconds while his top-of-the-line Xeon server takes two minutes to boot, or how a VAX shared among 80 users and with 1 Mb of ram gave good service to all of them. He quoted someone from Microsoft to the effect of Software gets slower faster than hardware gets faster Ah, and another good quote - Software is gas - it grows to use all of its container. (He then goes on to a different path - explaining why Minix 3's tiny amount of kernel-mode code is important in a world of bloated software). knows what). What I can't understand is when the memory of such a program grows over time, forcing you to reboot every week (like you said). Maybe it's not the clock applet. You can't 100% deduct it from the data so far, can you? Contrast this to more modern software, which leaks megabytes *every day* (if not every hour), and nobody is even trying to do anything about it... Alas... Indeed. I remember in my degree studies, Prof. Tarsi tried to explain why it's important to write more efficient programs even as you run on faster hardware, as much as people appreciate his intelligence, the argument didn't always come across... Then again - that's why there is enough work for GOOD programmers...:) --Amos
Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
And can something be done about it ?? Just as an example at how ludicrous the situation is (and the reason that my relatively powerful laptop is grinding to a halt at the most opportune times of the day), disregarding the things that need to be big, such as Evolution which I'm willing to let go at the moment although it does take up 1 - 1.5GB of virtual memory, here is the list of the things that I don't understand: PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2994 root 15 0 241M 40512 10032 S 2.0 1.1 2h23:59 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.X X is here for reference - it takes up ~200 - 250MB of virtual and it has the excuse that it needs to be big. lets look at the stuff that take about the same amount of virtual: 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus --sm-config-prefix /nautilus-wyDKQV/ --s Nautilus at idle - I don't have any file manager window open and I'm not copying or doing any file operation that requires nautilus - it just needs to draw the desktop when I have it exposed (which is not that often, I like to work with maximized windows and use a lot of workspaces). Still it takes almost as much virt as X does. 3166 odeda 18 0 186M 23408 10932 S 0.0 0.6 1:20.29 gnome-panel --sm-config-prefix /gnome-panel-IoBUz The panel is kept busy on my system with quite a lot of applets - but it still is no excuse for 186MB of memory, mainly as applets are out-of-process and counted separately.. lets look at what applets are doing: 3310 odeda 16 0 181M 32696 4344 S 0.0 0.9 5:55.44 /usr/libexec/netspeed_applet2 --oaf-activate-iid= The network monitoring applet - shows a small box with the amount of bytes being passed through the interface at the moment. It also graphs network history for the last 5 minutes or so - still it uses 180MB, almost 20% of my total dynamic memory. I cringe to think about what people with 512MB memory do. 3490 odeda 15 0 131M 7308 5456 S 0.0 0.2 0:26.75 mono /usr/lib/tomboy/Tomboy.exe --panel-applet -- Note taking application. written in mono, so I'll let it go. 3327 odeda 15 0 120M 5336 4504 S 0.0 0.1 0:01.03 /usr/libexec/trashapplet --oaf-activate-iid=OAFII The trash applet ? its a frigging two-state icon, with a tooltip that counts the number of items in the trash folder - why does it need 120MB of memory ?? 3307 odeda 15 0 115M 6188 4612 S 0.0 0.2 0:55.20 /usr/libexec/gnome-netstatus-applet --oaf-activat Here's another network applet - this one shows wireless signal. Unlike its brother, this one doesn't have a history - I guess that's why it only takes 115MB of memory !! I took a snapshot of this right after my system wasn't responding and I had to ssh from another computer and kill some processes before I managed to get in, so this doesn't list some other stuff which eats a lot of memory, such as the sensor applet (~180MB), the task bar applet (~150MB !!) and gaim - which is a nice IM and all, but shouldn't take close to 300MB of memory. Just for comparison, I also use some KDE apps (that are written in bloated C++, right ?): Amarok (fully loaded with about 3GB of music to monitor): ~200MB Kopete (under same conditions as GAIM): ~70MB Kmail (under same conditions as evo above): ~110MB Basket (a note taking application - here as a comparison with GNOME applets - its not an applet, but it is constantly running and has a rather complex UI and carries more data for me then tomboy above): ~40MB Now before you go all its only virtual, who cares, I'll have you know that my OS is set up with 2GB of swap for 1GB of dynamic memory, which I always thought was good enough for almost everything, and still - when I have firefox, evolution, some text editors and maybe some file manager windows (in additions to the stuff I always keep running, of course) switching is a pain. If I want to add a serious IDE to the mix, I know I'm risking it. And every so often - about twice a week - I get a system that is so unresponsive due to swap thrashing (if I log in remotely I can see swap at 100% and kswapd taking up all the resources), that I have to kill X just to gain control over it. Except for switching back to KDE - any idea what I can about this ? -- Oded ::.. Chaos is but unperceived order. -- Fred Hoyle = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
VIRT stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card's RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment. http://gentoo-wiki.com/FAQ_Linux_Memory_Management#The_difference_among_VIRT.2C_RES.2C_and_SHR_in_top_output = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
--=-Yb50PNKHYNSNAArM+xQe Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2007-01-16 at 12:09 +0200, Constantine Shulyupin wrote: VIRT stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card's RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment. I'm assuming that shared library mmaped are counted in the shared section, which is neglegable - for all GNOME apps and applets, even evo with a 1.5GB footprint is never more then 20MB. What other stuff is mmaped ? I don't think that disregarding the VIRT value when checking memory consumption is wrong, as an application with a large memory footprint is more likely to swap, swapping is expensive and if a lot of applications (virtually any single tine little GNOME applet I'm using) are swapping, it can easily bring down a powerful computer. -- Oded ::.. Clinton lied. A man might forget where he parks or where he lives, but he never forgets oral sex, no matter how bad it is. -- Barbara Bush (Former US First Lady) --=-Yb50PNKHYNSNAArM+xQe Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 TRANSITIONAL//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; CHARSET=UTF-8 META NAME=GENERATOR CONTENT=GtkHTML/3.12.2 /HEAD BODY On Tue, 2007-01-16 at 12:09 +0200, Constantine Shulyupin wrote: BLOCKQUOTE TYPE=CITE PRE FONT COLOR=#00VIRT stands for the virtual size of a process, which is the sum of/FONT FONT COLOR=#00memory it is actually using, memory it has mapped into itself (for/FONT FONT COLOR=#00instance the video card's RAM for the X server), files on disk that/FONT FONT COLOR=#00have been mapped into it (most notably shared libraries), and memory/FONT FONT COLOR=#00shared with other processes. VIRT represents how much memory the/FONT FONT COLOR=#00program is able to access at the present moment./FONT /PRE /BLOCKQUOTE BR I'm assuming that shared library mmaped are counted in the quot;sharedquot; section, which is neglegable - for all GNOME apps and applets, even evo with a 1.5GB footprint is never more then 20MB. What other stuff is mmaped ?BR BR I don't think that disregarding the VIRT value when checking memory consumption is wrong, as an application with a large memory footprint is more likely to swap, swapping is expensive and if a lot of applications (virtually any single tine little GNOME applet I'm using) are swapping, it can easily bring down a powerful computer.BR BR TABLE CELLSPACING=0 CELLPADDING=0 WIDTH=100% TR TD --BR OdedBR ::..BR quot;Clinton lied. A man might forget where he parks or where he lives, but he never forgets oral sex, no matter how bad it is.quot;BR nbsp;nbsp;nbsp;nbsp;-- Barbara Bush (Former US First Lady)BR BR /TD /TR /TABLE /BODY /HTML --=-Yb50PNKHYNSNAArM+xQe-- = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, Jan 16, 2007, Oded Arbel wrote about Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: And can something be done about it ?? I'll offer only partial explanations; I hope that someone else can offer better exlanations, and/or a solution. Of course, my own solution is simple: I don't use neither Gnome, nor KDE. I hand-pick individual applications which I like. I picked a window manager (called ctwm), an editor, clock, and so on, each separately based on their own merits. And one of these merits were memory use (my home computer has just 256 MB of memory, so low memory use is very important for me). PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2994 root 15 0 241M 40512 10032 S 2.0 1.1 2h23:59 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.X X is here for reference - it takes up ~200 - 250MB of virtual and it has the excuse that it needs to be big. Maybe you already know this, but let me just verify that we're on the same page. VIRT is the amount of virtual memory that the process has mapped. It isn't certain that all this memory is used, or ever been used - it is possible that the program allocated some memory and never used it and it doesn't take up space anywhere (I'll get back to this issue shortly). Even stranger (but true), it is possible that this virtual memory isn't RAM at all, but a mapping of a file (such as a shared library), or of something else. In the X server case, it is very common for the server to map the graphic card's memory, which often results in very high virtual memory figures for the X server. The RES figure is the amount of memory that the program now currently uses. You can see that the X server actually uses much less memory than that VIRT figure. lets look at the stuff that take about the same amount of virtual: 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus --sm-config-prefix /nautilus-wyDKQV/ --s Nautilus at idle - I don't have any file manager window open and I'm not copying or doing any file operation that requires nautilus - it just needs to draw the desktop when I have it exposed (which is not that often, I like to work with maximized windows and use a lot of workspaces). Still it takes almost as much virt as X does. What can explain huge VIRT size and small RES figure at the same time? I can offer several possibilities - I don't know which of these applies to Nautilus (or your other examples): 1. Software which only knows how to grow, but not shrink. Consider for example Firefox; At some stage in time, you had 10 tabs open, each with very complex pages. Later, you close all the tabs but one, but none of the free()ed memory is actually returned to the system. All this unused memory wasted space in the swap, but doesn't waste RAM. This sort of problem is very common for monolithic programs (which, unlike the original Unix philosophy, don't run quickly and exit, and don't run subprocesses). 2. Programs which uses a lot of threads. Each thread has its own stack; In Linux, these stacks have fixed sized (they don't grow dynamically like the heap) and needs to be allocated in advance. Traditionally, each thread had a 8 MB stack, so if your program had 10 threads, it would allocated 80 MB of virtual memory even without doing a thing! This 80 MB would turn up on the VIRT number but would not actually consume any resources (not RAM and not swap space). If I remember correctly, the per-thread stack size was later reduced to 2 MB which is more reasonable, but still can explain some of the VIRT size for multi-threaded programs. 3. Programs which use a lot of shared libraries. Shared libraries are great. They allow executables to be smaller, and less memory to be used when a lot of applications are running. However, when a program uses a shared library, it maps it into memory, and the shared library size gets added to the VIRT number. Gnome and KDE applications use tons of shared libraries, so even before they allocate a single byte, a huge size is already added to their VIRT figure. Note that while shared libraries increase the VIRT figure, they do not actually consume resources (RAM or swap space), so they are not bad. Check out /proc/.../maps to see which shared libraries are mapped by some process. 3310 odeda 16 0 181M 32696 4344 S 0.0 0.9 5:55.44 /usr/libexec/netspeed_applet2 --oaf-activate-iid= The network monitoring applet - shows a small box with the amount of bytes being passed through the interface at the moment. It also graphs network history for the last 5 minutes or so - still it uses 180MB, What worries me here is not the 181M VIRT figure (which like I explained, could mean nothing), but rather the 32 MB RES figure. This crappy applet really takes up 32 MB of your real RAM. This is inexcusable. Just to compare, here are some RES figures for a few
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
SWAP (key 'p') The size of swapped out portion of a task's virtual memory image. This field is sometimes confusing, here is why: Logically, you would expect this field really shows whether your program is partially swapped out and how much. But the reality shows otherwise. Even the Swap used field shows 0, you will be surprised that SWAP field of each tasks show greater than zero number. So, what's wrong? This comes from the fact that top use this formula: VIRT = SWAP + RES or equal SWAP = VIRT - RES As explained previously, VIRT includes anything inside task's address space, no matter it is in RAM, swapped out or still not loaded from disk. While RES represents total RAM consumed by this task. So, SWAP here means it represents the total amount of data being swapped out OR still not loaded from disk. !!! Don't be fooled by the name, it doesn't just represent the swapped out data. !!! http://www.linuxforums.org/misc/using_top_more_efficiently_3.html On 1/16/07, Oded Arbel [EMAIL PROTECTED] wrote: On Tue, 2007-01-16 at 12:09 +0200, Constantine Shulyupin wrote: VIRT stands for the virtual size of a process, which is the sum ofmemory it is actually using, memory it has mapped into itself (forinstance the video card's RAM for the X server), files on disk thathave been mapped into it (most notably shared libraries), and memoryshared with other processes. VIRT represents how much memory theprogram is able to access at the present moment. I'm assuming that shared library mmaped are counted in the shared section, which is neglegable - for all GNOME apps and applets, even evo with a 1.5GB footprint is never more then 20MB. What other stuff is mmaped ? I don't think that disregarding the VIRT value when checking memory consumption is wrong, as an application with a large memory footprint is more likely to swap, swapping is expensive and if a lot of applications (virtually any single tine little GNOME applet I'm using) are swapping, it can easily bring down a powerful computer. -- Oded ::.. Clinton lied. A man might forget where he parks or where he lives, but he never forgets oral sex, no matter how bad it is. -- Barbara Bush (Former US First Lady) -- Constantine Shulyupin Embedded Linux Consultant 054-4234440 http://linuxdriver.co.il/
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Hello Oded, people... Few weeks ago, I worked temporarily at a small company, and they gave me a PC which was with Athlon XP (if I recall it was 1.6 Ghz or something) with 756MB RAM to work with. So, I installed CentOS 4.4, upgraded my KDE 3.5.5, and upgraded OpenOffice to the latest one, and used FireFox 2 for browsing. I started to work. I started to use OpenOffice to write a small spreadshot. BOY was it slow as hell! it was so slow that I was almost sure I had some Pentium 2 300Mhz processor. Switching apps (using ALT TAB) was a PITA. I have not been running many applications: Twinkle, Kopete, FireFox, KMail, OO, and Konsole. Nothing more. The machine was crawling. I took Office 2003 from the Windows team, installed Crossover 6 (the latest version finally solves the flickering flash bug), and started to use Office 2003. Finally I could write somthing without the machine being crawling, but opening few more tabs in FF 2, and the machine crawled again.. My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. I heard my advocates who recommend people to switch to Linux and use KDE or GNOME with 256MB RAM. To them I can say HA HA! go ahead, fire the latest GNOME and open 2-3 apps and give the machine a minute or so, it will be almost unresponsive. It's better in KDE but not by much. If someone wants something speedy, they should look at using FVWM, flux box or any other lite window manager and use some independent applications. I used FVWM with Kopete and KMAIL and Konqueror, and the results were pretty good on a 192MB machine. I tried to switch to GNOME (yes, stupid decision) and I had to reset the machine in order to get my control back. Today, everyone is laughing/amazed by the hardware requirement of Windows VISTA (specially with Aero Glass interface). Well, my friends, at this pace, GNOME (and maybe even KDE) is going at this way, with all the latest GLX eye-candy, and the hefty memory requirements. I do not know the future, but I do remember KDE usage only few years ago with a Pentium 4 1.7Ghz, 512MB RAM, and it was very usable and enjoyable. Thanks, Hetz On 1/16/07, Oded Arbel [EMAIL PROTECTED] wrote: And can something be done about it ?? Just as an example at how ludicrous the situation is (and the reason that my relatively powerful laptop is grinding to a halt at the most opportune times of the day), disregarding the things that need to be big, such as Evolution which I'm willing to let go at the moment although it does take up 1 - 1.5GB of virtual memory, here is the list of the things that I don't understand: PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2994 root 15 0 241M 40512 10032 S 2.0 1.1 2h23:59 /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.X X is here for reference - it takes up ~200 - 250MB of virtual and it has the excuse that it needs to be big. lets look at the stuff that take about the same amount of virtual: 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus --sm-config-prefix /nautilus-wyDKQV/ --s Nautilus at idle - I don't have any file manager window open and I'm not copying or doing any file operation that requires nautilus - it just needs to draw the desktop when I have it exposed (which is not that often, I like to work with maximized windows and use a lot of workspaces). Still it takes almost as much virt as X does. 3166 odeda 18 0 186M 23408 10932 S 0.0 0.6 1:20.29 gnome-panel --sm-config-prefix /gnome-panel-IoBUz The panel is kept busy on my system with quite a lot of applets - but it still is no excuse for 186MB of memory, mainly as applets are out-of-process and counted separately.. lets look at what applets are doing: 3310 odeda 16 0 181M 32696 4344 S 0.0 0.9 5:55.44 /usr/libexec/netspeed_applet2 --oaf-activate-iid= The network monitoring applet - shows a small box with the amount of bytes being passed through the interface at the moment. It also graphs network history for the last 5 minutes or so - still it uses 180MB, almost 20% of my total dynamic memory. I cringe to think about what people with 512MB memory do. 3490 odeda 15 0 131M 7308 5456 S 0.0 0.2 0:26.75 mono /usr/lib/tomboy/Tomboy.exe --panel-applet -- Note taking application. written in mono, so I'll let it go. 3327 odeda 15 0 120M 5336 4504 S 0.0 0.1 0:01.03 /usr/libexec/trashapplet --oaf-activate-iid=OAFII The trash applet ? its a frigging two-state icon, with a tooltip that counts the number of items in the trash folder - why does it need 120MB of memory ?? 3307 odeda 15 0 115M 6188 4612 S 0.0 0.2 0:55.20 /usr/libexec/gnome-netstatus-applet --oaf-activat Here's another network applet - this one shows wireless signal. Unlike its brother, this one doesn't have a history - I guess that's
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 12:27 +0200, Nadav Har'El wrote: Of course, my own solution is simple: I don't use neither Gnome, nor KDE. I hand-pick individual applications which I like. Not an option for me, but thanks for the offer :). I like to have my apps tightly integrated. X is here for reference - it takes up ~200 - 250MB of virtual and it has the excuse that it needs to be big. The RES figure is the amount of memory that the program now currently uses. You can see that the X server actually uses much less memory than that VIRT figure. As I've said - I use X as a reference to something which has a big VIRT, makes sense that has a big VIRT and its ok that it has a big VIRT (because it holds image buffers, and maps large chunks of memory from the graphics adapter). I'm saying that it makes no sense for software which is much less complex then X to take as much as X. lets look at the stuff that take about the same amount of virtual: 3170 odeda 18 0 204M 17932 6556 S 0.0 0.5 3:52.88 nautilus --sm-config-prefix /nautilus-wyDKQV/ --s What can explain huge VIRT size and small RES figure at the same time? I can offer several possibilities - I don't know which of these applies to Nautilus (or your other examples): 1. Software which only knows how to grow, but not shrink. ... All this unused memory wasted space in the swap, but doesn't waste RAM. My problem is not wasted RAM - its over-used swap. I'm aware of the problem with Firefox (and any Java program), so I wasn't going to mention them. I really hope that GNOME doesn't have that problem. 2. Programs which uses a lot of threads. GNOME programs are usually very light on threads. I don't see any reason for an applet to use more then a thread or two. 3. Programs which use a lot of shared libraries. Unless I'm mistaken, shared libraries are counted in the SHR section, which is relatively small for GNOME programs - less then 20MB. Assuming its not (2) or (3) - does it has to be (1) (programs that don't free memory) ? I was always under the assumption that GNOME programs are more in touch with the UNIX way of doing things (the one true way), and their programs would not suffer from the same issues as Firefox and Sun's JVMs. -- Oded ::.. What boots up must come down. -- Net Philosophies = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 12:40 +0200, Constantine Shulyupin wrote: SWAP (key 'p') The size of swapped out portion of a task's virtual memory image. Are you talking about a field that shows how much memory a task has swapped out ? I don't see where you can get that info - I only see VIRT, RES and SHR when I ps, top or (my favorite) htop. When I say that my system has swap swamped, I mean that running 'free' shows almost 0 in the 'free' column for the 'swap' record. -- Oded ::.. But in our enthusiasm, we could not resist a radical overhaul of the system, in which all of its major weaknesses have been exposed, analyzed, and replaced with new weaknesses. -- Bruce Leverett, Register Allocation in Optimizing Compilers = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On 16/01/07, Oded Arbel [EMAIL PROTECTED] wrote: And can something be done about it ?? In parallel to the other comments - I use GNOME 2.14.3 on Debian Etch on an Athlon XP 2500+ (a 1.1GHz processor) with 1.25Gb ram and can't remember when I last saw this system use its swap since I upgraded from 512Mb. I'm not saying this is an ideal situation, it still uses 47% of its RAM for programs (and the rest for cache) and it's still slow (I tend to blame the CPU and the old graphics card) but it's far from the situation people here describe about their GNOME performance. I mostly use Firefox, with Skype, a few gnome terminals (which I heard are notorious for memory leaks) and the occasional OpenOffice application, and currently my system is up for over two days (apparently had a power failure over the weekend when I was outside home). So whatever is your conclusion - this is just another data point that maybe the problem is not totally generic to GNOME but maybe you should look for some additional causes in your particular setup. --Amos
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
run top then press f and p On 1/16/07, Oded Arbel [EMAIL PROTECTED] wrote: On Tue, 2007-01-16 at 12:40 +0200, Constantine Shulyupin wrote: SWAP (key 'p') The size of swapped out portion of a task's virtual memory image. Are you talking about a field that shows how much memory a task has swapped out ? I don't see where you can get that info - I only see VIRT, RES and SHR when I ps, top or (my favorite) htop. When I say that my system has swap swamped, I mean that running 'free' shows almost 0 in the 'free' column for the 'swap' record. -- Oded ::.. But in our enthusiasm, we could not resist a radical overhaul of the system, in which all of its major weaknesses have been exposed, analyzed, and replaced with new weaknesses. -- Bruce Leverett, Register Allocation in Optimizing Compilers -- Constantine Shulyupin Embedded Linux Consultant 054-4234440 http://linuxdriver.co.il/ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 16 Jan 2007, Oded Arbel wrote: And can something be done about it ?? Don't run Gnome, run fvwm like me ;-) You want eye candy, you got eye candy. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 22:35 +1100, Amos Shapira wrote: On 16/01/07, Oded Arbel [EMAIL PROTECTED] wrote: And can something be done about it ?? In parallel to the other comments - I use GNOME 2.14.3 on Debian Etch on an Athlon XP 2500+ (a 1.1GHz processor) with 1.25Gb ram and can't remember when I last saw this system use its swap since I upgraded from 512Mb. I'm not saying this is an ideal situation, it still uses 47% of its RAM for programs (and the rest for cache) [...] and currently my system is up for over two days (apparently had a power failure over the weekend when I was outside home). I usually see a problem after about a week of usage - after a reboot it behaves itself for a few days. I rebooted this morning, and now Evo is down to 400MB. So whatever is your conclusion - this is just another data point that maybe the problem is not totally generic to GNOME but maybe you should look for some additional causes in your particular setup. I'm using a default Fedora setup, with hardly any locally compiled software (and none that is used on a day-to-day basis). From my experience with other installations, this is common to any modern Linux OS running a fully featured desktop (GNOME more then KDE, but I can't say that its not happening with KDE) for more then a week of uptime. -- Oded ::.. Show me a sane man and I will cure him for you. -- Carl Gustav Jung (1875-1961) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 2007-01-16 at 12:40 +0200, Constantine Shulyupin wrote: SWAP (key 'p') The size of swapped out portion of a task's virtual memory image. This field is sometimes confusing, here is why: Logically, you would expect this field really shows whether your program is partially swapped out and how much. But the reality shows otherwise. Even the Swap used field shows 0, you will be surprised that SWAP field of each tasks show greater than zero number. So, what's wrong? This comes from the fact that top use this formula: VIRT = SWAP + RES or equal SWAP = VIRT - RES As explained previously, VIRT includes anything inside task's address space, no matter it is in RAM, swapped out or still not loaded from disk. While RES represents total RAM consumed by this task. So, SWAP here means it represents the total amount of data being swapped out OR still not loaded from disk. I see. I don't think SWAP is exactly VIRT - RES: for example, the sensors applet has VIRT 94MB, RES 15MB and SHR 8M, but SWAP is listed as 75MB. For most apps, it looks as if SWAP is indeed = VIRT - RES which, if RES includes SHR, seems to me to indicate that all the memory mapped to the task is either resident or swapped: which is consistent with my feel of the system where when the accumulated VIRT of all the processes about equals available swap space + dynamic memory then the system breaks. -- Oded ::.. Hey Mr. postman look and see, what you have in the bag for me. It could be a bomb or it could be a letter - it doesn't matter, things can only get better. -- 'When the rainbow comes' / Paula Cole = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, Jan 16, 2007, Oded Arbel wrote about Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: I usually see a problem after about a week of usage - after a reboot it behaves itself for a few days. I rebooted this morning, and now Evo is down to 400MB. With the mad race to get better and better hardware, it seems that people forgot how to write efficient software. One of the lost arts is preventing memory leaks. There are two kind of memory-leak-like problems in modern software: 1. Real memory leaks, where the program grows, and grows, and grows, the longer it runs. 2. The program not being able to shrink its memory use, and therefore each long-running program always takes the maximum amount of memory it needed up until now. (Every mathematician learned that sum(max(...)) max(sum(...)), which is why this is such a serious problem when you're running many programs). I can, if I try very hard, understand why some clock applet should take 10 MB of memory (because it uses inefficient overly-general libraries, because it has translations into 100 different languages loaded into memory, or who knows what). What I can't understand is when the memory of such a program grows over time, forcing you to reboot every week (like you said). About a year ago, I discovered a memory leak in my favorite window manager, ctwm: I noticed that after several months (!) of continuous use, it used up a few megabytes more than it used initially. I bit of debugging (with a memory leak-finding tool that I wrote) turned out that ctwm leaked a few bytes of memory for every new window opened. After you open tens of thousands of windows over a few months, this adds up to a few megabytes. I reported the bug, and it was fixed. Contrast this to more modern software, which leaks megabytes *every day* (if not every hour), and nobody is even trying to do anything about it... Alas... -- Nadav Har'El| Tuesday, Jan 16 2007, 26 Tevet 5767 [EMAIL PROTECTED] |- Phone +972-523-790466, ICQ 13349191 |A witty saying proves nothing. -- http://nadav.harel.org.il |Voltaire = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Gnome has *footprint* for a logo - since forever, and for a very good reason. Somehow people don't get the hint until it is too late... -- Oleg Goldshmidt | [EMAIL PROTECTED] | http://www.goldshmidt.org = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, 16 Jan 2007, Oleg Goldshmidt wrote: Gnome has *footprint* for a logo - since forever, and for a very good reason. Somehow people don't get the hint until it is too late... Yes ... the image is incomplete, it lacks an ideogram of the mouth in which the foot is placed. Peter (neither gnome nor kde) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, Jan 16, 2007 at 12:47:03PM +0200, Hetz Ben Hamo wrote: My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. OpenOffice and Firefox are not developed by either gnome or KDE. Actually it seems that KDE apps are reasonably efficient. Gnome uses Gecko as an HTML rendering engine and thus is not entirely off the hook regarding FireFox. I heard my advocates who recommend people to switch to Linux and use KDE or GNOME with 256MB RAM. To them I can say HA HA! go ahead, fire the latest GNOME and open 2-3 apps and give the machine a minute or so, it will be almost unresponsive. It's better in KDE but not by much. If someone wants something speedy, they should look at using FVWM, flux box or any other lite window manager and use some independent applications. I used FVWM with Kopete and KMAIL and Konqueror, and the results were pretty good on a 192MB machine. I tried to switch to GNOME (yes, stupid decision) and I had to reset the machine in order to get my control back. If you use Konqueror and KMail there isn't much to gain from using fvwm as the WM (memory-wise). I tried using KDE recenly in a system with 128MB. Basically usable. Sadly kword is not usable enough and thus OOo has to be used, which is a loading and swapping pain. -- Tzafrir Cohen | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il || a Mutt's [EMAIL PROTECTED] || best ICQ# 16849755 || friend t = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tuesday, 16 בJanuary 2007 12:47, Hetz Ben Hamo wrote: My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. Completely agreed. I think it's bound to happen Real-Soon-Now(tm) because of several factors: - Linux is penetrating some semi-embedded markets (think Nokia 770 and its successors). These require trimming classic desktop components. This means there are people which the knowhow and the time/budget to invest in this. (e.g: Mozilla -- Minimo) - Linux is accelerating in 3'rd world countries which use low end hardware. One interesting example is OLPC which already push various components of Fedora to trim down. -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 But it does move! -- Galileo Galilei = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On the contrary to all said on this thread, I must admit that using KDE with 512 MB is quite sane. I am using this setup on a machine running Etch. kmail running for several weeks, same as akregator, Firefox 2 running on and off, konsole is usually open. The machine is very responsive a hour after I start using it every day (stupid debian updates take 20 minutes every other day, sometimes even 40 if I do not update several days). Uptime is ~60 days using a stock kernel (I actually took a kernel.org source and compiled it into *.deb, quite cool). I am also running OpenSUSE 10.1 on a very broken system (PS/2 connections does not work, and 2nd IDE is completely dead), this is why I don't have high uptimes on that machine. However, this machine has 512mb of memory, which serves me to run Firefox2, Mozilla, a full KDE desktop and all other goddies (I tried even Beryl, which I just did not like, I went back to kwin). I even run 2 X sessions on the same time: the stock SuSE desktop and the stock KDE 3.x (or 4.X) compiled from sources. Quite frankly, it works pretty good. I assume more patient is needed, but hey, nothing comes for free. Anyone else running KDE and feeling the same as me? I understand that gnome is not a pretty sight, but I would like to know what other people think of KDE :) ביום שלישי 16 ינואר 2007, 16:10, נכתב על ידי Nadav Har'El: On Tue, Jan 16, 2007, Oded Arbel wrote about Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: I usually see a problem after about a week of usage - after a reboot it behaves itself for a few days. I rebooted this morning, and now Evo is down to 400MB. With the mad race to get better and better hardware, it seems that people forgot how to write efficient software. One of the lost arts is preventing memory leaks. There are two kind of memory-leak-like problems in modern software: 1. Real memory leaks, where the program grows, and grows, and grows, the longer it runs. 2. The program not being able to shrink its memory use, and therefore each long-running program always takes the maximum amount of memory it needed up until now. (Every mathematician learned that sum(max(...)) max(sum(...)), which is why this is such a serious problem when you're running many programs). I can, if I try very hard, understand why some clock applet should take 10 MB of memory (because it uses inefficient overly-general libraries, because it has translations into 100 different languages loaded into memory, or who knows what). What I can't understand is when the memory of such a program grows over time, forcing you to reboot every week (like you said). About a year ago, I discovered a memory leak in my favorite window manager, ctwm: I noticed that after several months (!) of continuous use, it used up a few megabytes more than it used initially. I bit of debugging (with a memory leak-finding tool that I wrote) turned out that ctwm leaked a few bytes of memory for every new window opened. After you open tens of thousands of windows over a few months, this adds up to a few megabytes. I reported the bug, and it was fixed. Contrast this to more modern software, which leaks megabytes *every day* (if not every hour), and nobody is even trying to do anything about it... Alas... = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
On Tue, Jan 16, 2007, Tzafrir Cohen wrote about Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?: My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. OpenOffice and Firefox are not developed by either gnome or KDE. They are not developed by Gnome or KDE, but they are based on the same monolithic if-we-take-up-a-lot-of-memory-the-users-will-just-buy-more philosophy. For the life of me I can't understand why XEmacs, the original kitchen sink that tries to do everything for everybody, takes memory in the order of 10-20MB, and OpenOffice often takes 10 times more. Actually it seems that KDE apps are reasonably efficient. Let's compare a few clock applications: app VIRTRES NOTE xdaliclock 3756796 oclock 36321540 xclock 85442976 kclock.kss 25840 8164 clock-applet (Gnome)90212 11256 (only the applet process) clock_panelapplet (KDE) 33664 12028 (for kicker with only a clock applet) This is nothing short of ridiculous. These integrated enviroments may be great for new users, but I can't for the life of me understand the justification of using so much memory for a clock applet. Even xclock's memory use surprised me, and it is just a third of what the KDE/Gnome applets appear to use. P.S. Offering some insight on why Gnome's VIRT figures are huge, which was the question that started this thread: Trying to understand where Gnome's clock-applet's huge VIRT comes from, I discovered something very interesting. It start with just 28 MB of VIRT, but at the moment you right-click on the clock, and a menu pops up, it grows to, belive it or not - 90 MB. That's 60 MB to show a menu !? I diffed the /proc/../maps, and this is what the extra 60 MB contain: 0.5 MB of newly allocated memory, plus a lot of mapped files; One interesting mapped file is the HUGE /usr/share/icons/crystalsvg/icon-theme.cache, taking up 28 MB of mapped space! But as I suspected, out of this 60 MB, most is read-only and mapped from files and thus takes up *zero* ram, and *zero* swap space. Other than giving a huge VIRT number, these mappings don't cause any harm. For the curious, here are the complete map diff, before and after I click on the menu: 0015a000-0015d000 r-xp 03:01 65215 /usr/lib/pango/1.5.0/modules/pango-hebrew-fc.so 0015d000-0015e000 rwxp 2000 03:01 65215 /usr/lib/pango/1.5.0/modules/pango-hebrew-fc.so 092df000-09431000 rw-p 092df000 00:00 0 092df000-094ae000 rw-p 092df000 00:00 0 b4056000-b40b6000 rw-s 00:08 19496969 /SYSV (deleted) b40b6000-b4bfe000 r--p 03:01 426187 /usr/share/icons/hicolor/icon -theme.cache b4bfe000-b6745000 r--p 03:01 848001 /usr/share/icons/crystalsvg/i con-theme.cache b6745000-b6e9b000 r--p 03:01 1630568/usr/share/icons/gnome/icon-t heme.cache b6e9b000-b7c2f000 r--p 03:01 1026257/usr/share/icons/Bluecurve/ic on-theme.cache b7c2f000-b7c3d000 r--p 03:01 2347542/usr/share/icons/Clearlooks/i con-theme.cache -- Nadav Har'El| Tuesday, Jan 16 2007, 27 Tevet 5767 [EMAIL PROTECTED] |- Phone +972-523-790466, ICQ 13349191 |This box was intentionally left blank. http://nadav.harel.org.il | = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Why are GNOME applications (and applets) take so much [EMAIL PROTECTED] memory ?
Hi, I am using GNOME-2.14.3+ desktop, all compiled from sources on a linux system, all compiled from sources with gcc-CVS-200608XX, using -march=athlon-xp on Athlon 2600+ (1917 MHz) with 256 MB RAM. I have experienced the GNOME memory usage problem before glibc-CVS-20060813. After upgrading glibc to that version, total memory usage have dropped below 82 MB, swap usage is 0 to ~200 KB. I am looking at xosview screen. I am running LyX (using pdflatex), Firefox, Inkscape, evince, java. I do not run GNOME clock applet, which runs full evolution-data-server. The system is very responsive, - Moshe Gorohovsky Tzafrir Cohen wrote: On Tue, Jan 16, 2007 at 12:47:03PM +0200, Hetz Ben Hamo wrote: My opinion: Some serious debate needs to be occured, whether in slashdor or the mailing lists, some sort of shake up in the GNOME/KDE development community, to remind them that this situation cannot be continue, and some diet is required. OpenOffice and Firefox are not developed by either gnome or KDE. Actually it seems that KDE apps are reasonably efficient. Gnome uses Gecko as an HTML rendering engine and thus is not entirely off the hook regarding FireFox. I heard my advocates who recommend people to switch to Linux and use KDE or GNOME with 256MB RAM. To them I can say HA HA! go ahead, fire the latest GNOME and open 2-3 apps and give the machine a minute or so, it will be almost unresponsive. It's better in KDE but not by much. If someone wants something speedy, they should look at using FVWM, flux box or any other lite window manager and use some independent applications. I used FVWM with Kopete and KMAIL and Konqueror, and the results were pretty good on a 192MB machine. I tried to switch to GNOME (yes, stupid decision) and I had to reset the machine in order to get my control back. If you use Konqueror and KMail there isn't much to gain from using fvwm as the WM (memory-wise). I tried using KDE recenly in a system with 128MB. Basically usable. Sadly kword is not usable enough and thus OOo has to be used, which is a loading and swapping pain. -- Moshe Gorohovsky A6 CC A7 E1 C2 BD 8C 1B 30 8E A4 C3 4C 09 88 47 Tk Open Systems Ltd. --- - tel: +972.2.679.5364, http://www.tkos.co.il - = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
