[PP]Investigate Linux mail/news code footprint



20 years ago
11 years ago


(Reporter: phil, Assigned: alecf)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PR1])



20 years ago
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


20 years ago
Target Milestone: M8

Comment 1

20 years ago
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.


20 years ago
Summary: Investigate Linux mail/news code footprint → [PP]Investigate Linux mail/news code footprint

Comment 2

20 years ago
Adding Alexander Larsson because he has spent some time investigating this.

Comment 3

20 years ago
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.

Comment 4

20 years ago
going on vacation, mass-moving these M8 bugs to M9

Comment 5

20 years ago
moving low priority, high risk, and time-intensive bugs to M10


20 years ago
Component: Front End → Back End
Target Milestone: M10 → M11


20 years ago
Whiteboard: [PR1]

Comment 6

20 years ago
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

Comment 7

20 years ago
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?

Comment 8

20 years ago
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.


20 years ago
Last Resolved: 20 years ago
Resolution: --- → WORKSFORME

Comment 9

20 years ago
works for me.

Comment 10

20 years ago
Alecf, QA has no resources to verify this bug. Please verify it or advise us how
to do it. thanks.


20 years ago
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.