7623 - [PP]Investigate Linux mail/news code footprint

Status: VERIFIED WORKSFORME

(MailNews Core :: Backend, defect, P3)

Description

[Phil Peterson]

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

Comment 1

[Alec Flett]

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.

Comment 2

[Alec Flett]

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

Comment 3

[Alec Flett]

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

[Alec Flett]

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

Comment 5

[Alec Flett]

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

Comment 6

[sol]

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

[Alec Flett]

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

[ramiro]

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.

Comment 9

[Alec Flett]

works for me.

Comment 10

[fenella]

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