GNOME.org
 

Re: Low memory hacks

Rodney Lorrimar wrote:

On Mon, Mar 17, 2008 at 02:22:44AM +0000, Simos Xenitellis wrote:

Bastien Nocera wrote:

On Mon, 2008-03-17 at 00:56 +0000, Simos Xenitellis wrote:

On Sun, Mar 16, 2008 at 11:25 PM, Bastien Nocera <hadess hadess net> wrote:

 On Sun, 2008-03-16 at 14:02 +0000, Simos Xenitellis wrote:
 <snip>


That is a saving of at least 3M in memory.

 >
 > The stripping of "unneeded" messages is good, and should happen at the
 > package generation level (not in GNOME, or when creating tarballs).

 You talk about memory savings, but do calculations based on file sizes.
 That's doesn't work.

Aren't mo files mapped to memory?

Yes, they're mapped. That doesn't result in actual memory usage. The
kernel will make sure they're only read into memory as needed.

Is there a tool that shows which pages are in memory and which are in swap?
I do not know of such a tool, so I would expect the worst case scenario of all pages being in memory. 

On Linux, exmap can tell you this. It gives two figures, "effective
resident" and "effective mapped". It counts each 4k page which is
loaded. You can see the .mo files which are mapped into memory, how
many pages are mapped, and which processes map the file. Unfortunately
the website has gone offline, and that is the only place I know which
has the documentation (have e-mailed the author about it). There are 2
user interfaces:

http://www.berthels.co.uk/exmap
http://projects.o-hand.com/exmap-console

For example, I have an Ubuntu 7.10 desktop with a few programs running
(a couple standard applets, nautilus, gimp, epiphany, gcalctool) and
LANG=pl_PL.UTF-8. exmap-console and gnumeric tell me the mapped memory
usage of all .mo files is 1584kb.
I tried out exmap-console. There are there columns with numbers for the MO files, labeled "sole", "file" and "file-VM". "sole" is apparently the memory in multiples of page size, that can fit the file. 
I do not know what is the difference between "file" and "file-VM".
If "file" is the amount of memory that is being used currently, then,

* in Ubuntu 7.10
* with en_GB.UTF-8 (fixed)
* with gimp, iagno, nautilus open (Firefox, Thunderbird, OOCalc do not appear as .mo files) * installation deviates from typical (for example, no accessibility enabled). 

the number that OOCalc gives is 2,420,736 bytes.

While,
* in Ubuntu 8.04 (alpha6), i.e. stripped MO files,
* with en_GB.UTF-8
* with gimp, iagno, nautilus open
* standard installation, (=accessibility enabled)

the number that OOCalc gives is 1,646,592.

The difference is over 700KB of memory.

For reference, for Greek, the memory use is about 5.8MB (Ubuntu 8.04Alpha).
The messages in a .mo file are in no specific order, so I would expect that within a page there should be at least a message an application requires at any time.
The important part, however, is that when a translation is exactly the same with the original message, then this entry is not required to exist in the MO file; the running application can find the original message withing the application itself. By stripping the MO file of such messages, the file size reduces and most probably there is reduction in memory use (between 0 to .mo file size).
Is this description clear? Do you think that the savings would be so minimal that one would not need to bother working on this? 

Could be... what percentage of translations in en_GB do you think are
duplicates? Was it 86% (100% - 2MB/14MB) ?
This amount of translation strings are not required for the correct representation of en_GB (pending the issue that Danilo raised). 

Simos
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]