The mail/news code for Linux is more than twice as large as Win32. Please find out why this is and make whatever improvements are possible. Win32 Linux addrbook 53248 95808 local mail 90112 303096 compose 86016 193512 mailnews 65536 127620 mime 98304 156892 imap 147456 324104 news 90112 173192 db 126976 90324 baseutil 100900 mork 284364 vcard 49152 70840 htmlemitter 20480 14280 xmlemitter 20480 14132 rawemitter 20480 12056 total 815104 1865312
I have some thoughts on this, we might just be running into massive symbol tables... I'm adding some other local unix experts: bruce, chris, ramiro, jim.
Summary: Investigate Linux mail/news code footprint → [PP]Investigate Linux mail/news code footprint
Adding Alexander Larsson because he has spent some time investigating this.
In a message to mozilla-unix, Alexander Larsson wrote: There is basically two main causes: First ELF libraries are compiled with position independent code so that the code section can be read-only and truly shared between all processes that links to it. Win32 on the other hand uses a relocation scheme so that if a process opens a dll that is already open, but it can't be placed at the exact same address it must be relocated again causing it to take more memory. The position independent code (PIC) takes more memory than non-PIC code. So basically linux trades of discspace for ram given that a library is used by several running processes. This is very good for things like libc, xlib and gtk, but might be suboptimal in the case of mozilla. The other problem is the symbol tables. The ELF shared libraries contain LARGE symbol tables for all global symbols and referenced symbols. PE dll's only contains strings for explicitly imported and exported symbols. This then clashes a bit with C++, in which all symbols are global (it seems). In C you normally use static functions to give file-scope to some symbols, but this doesn't seem possible in C++. I assume all method symbols from a class must be globally visible to create vtables or something. At least protected symbols need to be visible so that you can derive from that class in another file. This leads to a great many global symbols which gives large .hash, .dynsym and .dynstr sections in the ELF libraries.
going on vacation, mass-moving these M8 bugs to M9
moving low priority, high risk, and time-intensive bugs to M10
Component: Front End → Back End
Target Milestone: M10 → M11
It would be really good to get the size on Linux down for PR1. I'm assuming this is the memory footprint. I don't know what the typical Linux machine has in the way of RAM, but if our footprint for Linux is larger than what the user has available, that would be bad
this is size on disk. We haven't really been able to get it any smaller, as far as I know. Have we landed everyone's patches? Ramiro? Alex?
I landed Alex's patches, but the require compiler and linker hacks. So, for the short term until the tools get better, this is as good as it gets.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → WORKSFORME
works for me.
Alecf, QA has no resources to verify this bug. Please verify it or advise us how to do it. thanks.
You need to log in before you can comment on or make changes to this bug.