Compared to many non .NET and non Java applications on
windows I see that UI apps on my Ubuntu system often
show a high virtual memory consumption and also a high
resident memory portion. Nautilus for instance is often
at around 100MB virtual memory space and Firefox show
an even higher memory footprint.

Why is this so? Do these applications use statically
linked libraries more often than typical windows
applications?

Is it that the open source applications are not optimized
for a low footprint?

Have you made similar observations?

No, they don't use statically linked libs. However, the output
of top will report the same lib for each app that uses it, and
moreover it will report the *potential* size, in other words it
will make as if every single library that may be inherited some-
where along the line (whether any of the functions it may provide
are being used or not, and without regard whether to it being
actually loaded or not) needs to be represented in the vsize.



Cheers,
Tink

There are several relevant issues that any good operating system (OS) will consider, even though their designers may choose to report them to the user in different ways:

(1) Avoiding resource over-commitment: If you admit another unit-of-work into your system, you do not want to have "bitten off more than you can chew," and you cannot afford to discover the problem after-the-fact. Linux systems often run continuously for months and years, driving as much workload as they choose to accept. The OS needs to be able to predict the worst case.

(2) Accounting for shared resources: Every system has, somewhere, a pantheon of literally hundreds of libraries which programs open and use, from the venerable glibc right on down. No matter how many programs have the library open, they're all sharing the same copy: all of their virtual-memory address spaces are mapping the same pages.

• This creates another sort of over-commitment issue (glibc pages might have hundreds of "demand"ers, whereas my.first.program's pages will have only one: we don't want to "starve" a guy's first program out of having enough memory, yet we don't want to be paging glibc too much because that affects everybody.
• How do you report those shared resources when the user asks the innocent question, "how much memory is my.first.program using?" He thinks he's asking a simple question: he wants a simple answer. Do you include the shared resources, or not?

(3) "Laziness": A memory-management system won't do any work that it doesn't have to. If there is currently no pressure on the memory system, it won't go out of its way to page anything out. After all, someone might need those pages to be here a few milliseconds from now, and right no one in particular is insisting that they be gone (to make room for something else). So the memory manager just "catches a few more winks."

• This "laziness principle" is very important for, say, a CGI-based web server, which "runs a program" for every request that comes in. The program ends, so its address-space becomes "unused," but the memory-manager doesn't sweep it out the door because... Lo! Here comes another request, for the same program! Reattach to the same program-pages (they're still here), allocate a new empty data-segment and stack-segment, and we're ready to go (again).

I am too new to Linux to know for sure what the
"Virtual Memory" column in "System Monitor" really
means. The great thing about open source is that
it is only myself preventing me from finding out

But my initial question is actually misleading. These
comparatively high values have nothing to do with
Linux itself. It is only X based gnome applications
that show these high values. So it might simply be
that a bunch of libraries in this area have a very
large code set for which considerable virtual address
range is reserved to map them in when needed. And maybe very
little of this code is actually needed (the actually
resident amount of memory is much less).

The actual issue could therefore be that libraries
are just packaged in larger granularities than this
is typically done on windows systems.