On Dec 3, 2012, at 16:15 , Justin Lebar wrote:

> On Mon, Dec 3, 2012 at 5:39 PM, Norbert Lindenberg
> <mozillali...@lindenbergsoftware.com> wrote:
>> 
>> Well, the first question is what size increase would be acceptable given the 
>> benefits that ICU provides.
> 
>> I have currently trimmed it to 9.7 MB for the data library and 3.1 MB for 
>> two code libraries.
> 
> Ignoring download size for a moment, I want to consider the memory
> usage of this at runtime.

Memory usage on small devices certainly warrants some investigation and 
discussion. Unfortunately, I don't have real data yet.

> Does all of this data need to be loaded into memory?

Most of the data is locale data for several hundred locales, separated by 
locale and functionality, so as long as applications don't request a specific 
locale/functionality combination, it doesn't need to be loaded. Note though 
that the size of the data isn't uniform per locale - e.g., Chinese collation 
data is huge.

> If so, 13mb of code + data is likely unacceptable to B2G.  That's
> roughly 10% of all memory we have available to gecko on our devices.
> I would lobby hard against turning this on for B2G.

Understood. Now, how does B2G support internationalization in the absence of 
ICU?

> If we can avoid loading most of that data into memory, the situation
> is much better.  But even 3mb of code is dicey; we consider a 3mb
> memory win to be substantial and worthy of a large amount of effort to
> obtain.

Is all code loaded into memory as one lump on B2G, or is it paged in as needed? 
There may be quite a bit of code in there that's not commonly needed. The ICU 
documentation suggests static linking as a way to reduce code size - I haven't 
tried yet how much that would help.

> I'd imagine that the Fennec folks working on project 256mb [1] would
> have similar reactions.
> 
> On Windows desktop, our median memory usage is ~500mb, and the 5th
> percentile is ~175mb, so an extra 13mb, while not great, might be
> acceptable.  3mb wouldn't be a big deal.

Good to know.

Norbert

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to