On Fri, Feb 21, 2014 at 11:38 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > We now live in a memory-constrained world. By "we", I mean anyone > working on Mozilla platform code.
I realize that .so size matters much less than per-process heap-allocated stuff, but still: On the i18n front, there are binary size gains to be had by not building parts of ICU that we don't use. See https://bugzilla.mozilla.org/show_bug.cgi?id=944348 . (Before someone suggests using the ICU encoding converters: 1) We are building ICU converters that MUST NOT be exposed to the Web platform and we have no internal use for [e.g. BOCU-1] and 2) unless upstream ICU decides they want to track the Encoding Standard, replacing our converters with theirs may easily regress our Encoding Standard compliance, i.e. Web compatibility.) Also, in our own i18n code, there's a whole bunch of stuff that's dead code in Firefox (thanks to Encoding Standard work) but exposed in Thunderbird. The main problems are: 1) Gecko developers aren't really supposed to use time for Thunderbird development but unless comm-central burns, there's no sense of urgency from the Thunderdbird side to move stuff over, but making comm-central burn would be not be a polite way to make progress. 2) The Thunderbird developers aren't sure which bits they want to keep. Before ESR goes to release and people complain, no one *really* knows what needs to stay in TB. 3) There doesn't exist (see #1) a comm-central XPCOM module that could naturally receive (copy and paste) code from the m-c nsUConvModule. See https://bugzilla.mozilla.org/show_bug.cgi?id=937056#c3 An for something entirely different: Any chance static atoms could reside as plain old static C data structures in the data segment of libxul.so instead of being heap-allocated? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
