On 04/24/2014 05:49 AM, Till Schneidereit wrote: > Questions: > * Are we building and shipping dead code in ICU on B2G? > > I don't know the state of ICU on B2G, but if we have it enabled there, then > almost certainly, yes.
There's doubtless *some* dead code in the ICU we build, yes. (I don't remember whether we build ICU on b2g yet, tho.) Various ICU components were removed as part of building it into Mozilla (I'd have to check Makefile.in/moz.build to get a complete list). It's possible there are more, but I thought Norbert picked off the low-hanging fruit at the very least. Someone might be able to further split up ICU into subcomponents and pick off more, with enough investment of time in it. > * The bug about building useless code in ICU has been open since > November. Whose responsibility is it to make sure we stop building > stuff that we don't use in ICU? > > I guess that this isn't entirely clear. In practice it's largely no one's. I've been the one to update ICU the one time it's happened so far (we're due for another at this point, I just need to find time to do it). But that's just porting our patch set forward, plus debugging upstream issues. I have no particular expertise (beyond that of any random Mozillian) in tackling this sort of thing in ICU. > * Do we have any mechanisms in place for preventing stuff like the > ICU encoding converters becoming part of the building the future? When > people propose to import third-party code, do reviewers typically ask > if we are importing more than we intend to use? Clearly, considering > that it is hard to get people to remove unused code from the build > after the code has landed, we shouldn't have allowed code like the ICU > encoding converters to become part of the build in the first place? I agree in spirit, but this is kind of pedantic. I really don't think "clearly" is so obviously true, given that by nature of how we use ICU, we're only feeding it UChar/jschar/char16_t UTF-16 strings, so it's totally non-obvious how ICU encoders would ever be triggered. Not ideal, sure. But as we use it, encoders simply don't come into things, at least not in any user-visible way. (Conceivably they might be invoked in the back end when reading locale data from the file system, but that's presumably correctly encoded not as UTF-7 or so. It only really matters if the encoders are visible on the web, which I don't believe they are.) > I remember that back when Norbert first presented his Intl implementation > work at the JS work week in 2012, we discussed the impact ICU would have on > download size. One idea was to slim down the ICU build and get rid of some > things not needed for Intl. I might very well be mistaken, but I'm not aware > of this having happened. It happened. We removed a number of things like collation rules, some of the ICU components, and more beyond that. > We looked at what other vendors were doing and saw that Google essentially > just bundle all of ICU and swallow the increase in download size. Well, that was justification for shipping ICU. Not so much justification for shipping more of it than needed. > Also, properly integrating ICU into our build system was a major undertaking > in itself, so getting to a point where we could ship it at all might have > taken precedence. That's reasonably accurate, combined with the basic steps to prune size and built code having already been taken. If there's more of ICU that's easily pruned, I'm all for it. If pruning harder requires splitting ICU up into more components, that's fine, too. But someone has to do it, and my skills and knowledge lie elsewhere. Jeff _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
