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 <[EMAIL PROTECTED]> 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
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to