> > This is at least in part due to bug 915735, you can go and read the bug to > > see that I did the best I could there, given the constraints that I had > > (not understanding how the magic of the interaction of ICU and our build > > system worked, not understanding which parts of ICU we actually want to > > use, the performance and code quality limitations of MSVC's PGO compiler, > > the fact that increasing the amount of time we allow our builds to progress > > is rocket science, etc. > > I don’t have numbers for this change specifically, but during my > investigation I found that on Mac statically linking ICU into libmozjs > reduced the binary size by almost 600KB, compared to building ICU as a > separate DLL.
We should probably be able to make that difference smaller with a bit of work. We "just" need to get ICU to build in a configuration where the library only exports what we need, of course it would be better to just not build what we don't need. > On Apr 25, 2014, at 0:31 , Henri Sivonen <hsivo...@hsivonen.fi> wrote: > > > Therefore, it looks like we should turn off (if we haven't already): > > * The ICU LayoutEngine. > > * Ustdio > > * ICU encoding converters and their mapping tables. > > * ICU break iterators and their data. > > * ICU transliterators and their data. > > All done, except for a few remaining encoding converters: > > > However, that flag is misdesigned in the sense that it considers > > US-ASCII, ISO-8859-1, UTF-7, UTF-32, CESU-8, SCSU and BOCU-1 as > > non-legacy, even though, frankly, those are legacy, too. (UTF-16 is > > legacy also, but it's legacy we need, since both ICU and Gecko are > > UTF-16 legacy code bases!) > > http://mxr.mozilla.org/mozilla-central/source/intl/icu/source/common/unicode/uconfig.h#267 > > UTF-16 may be legacy from the point of view of encoding HTML pages, but > otherwise it’s an essential part of most of today’s computing environments – > and the alternative in many cases would be UTF-32. But at least four of the > above are clearly obsolete. for talking to win32 API sure, but win32 is a crazy beast, and we aren't using ICU for that anyway. > > Also, If the ICU build system is an configurable enough, I think we > > should consider identifying what parts of ICU we can delete even > > though the build system doesn't let us to and then automate the > > deletion as a script so that it can be repeated with future imports of > > ICU. > > That seems worth investigating, but getting the build system to strip out as > much as possible might be more effective – see the next item. easier probably, better no think of the hundreds of people who are stuck building it all the time. > On Apr 25, 2014, at 8:12 , Trevor Saunders <trev.saund...@gmail.com> wrote: > > > Well, it really depends how you approach the problem of finding code > > thats dead. One way is to decide code really should be dead by reading > > it and knowing what it accomplishes doesn't matter. Another is to > > prove to your self that code is unreachable and so can be removed > > without effecting anything. Both of these require a pretty good bit of > > knowledge and skill. On the other hand the below question prompts > > another approach. > > Is there a way to give the linker a list of functions that you want to have > as public entry points of a dynamically linked library, and have it strip out > everything that can’t be reached from these functions? That’s essentially > what happens when you statically link a library into another, and the list of > ICU functions that Mozilla code calls wouldn’t be excessively long. The bulk > of them can be found in this stubs section: > http://mxr.mozilla.org/mozilla-central/source/js/src/builtin/Intl.cpp#62 yes, though how hard they are to use with the ICU build system is left as an exercise for the reader. Trev > On Apr 28, 2014, at 5:59 , Henri Sivonen <hsivo...@hsivonen.fi> wrote: > > > I haven't looked into Ustdio. > > That’s disabled by the --enable-icuio=no flag in > http://mxr.mozilla.org/mozilla-central/source/build/autoconf/icu.m4#213 > > > However, I noticed that we aren't turning off ICU IDNA but we should: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1002435 > > Thanks for finding and fixing this issue, as well as 1002437! > > > On Apr 25, 2014, at 0:31 , Henri Sivonen <hsivo...@hsivonen.fi> wrote: > > > Using system ICU seems wrong in terms of correctness. That's the > > reason why we don't use system ICU on Mac and desktop Linux, right? > > Correctness from the user’s point of view – quality of locale and time zone > data – is clearly an issue (conformance with the Ecma standard is not, as > Jeff pointed out). In addition, a system ICU isn’t always available to us: On > Mac, it’s not public API; on some Linux versions, it’s built with version > numbers baked into function names, which we can’t link against. > > > On May 1, 2014, at 12:25 , Jeff Walden <jwalden+...@mit.edu> wrote: > > > On 04/28/2014 05:59 AM, Henri Sivonen wrote: > >> Hopefully we didn't remove collation rules, since that's the part we > >> are supposed to be using ICU for! :-) > > > > I'm uncertain exactly what the terminology means necessarily for us, but > > intl/icu-patches/genrb-omitCollationRules.diff exists because a flag passed > > in the ICU build process to "omit collation rules" was broken in 52, and we > > had to fix it ourselves. (Well, technically I wrote a patch-fix, submitted > > it upstream, then they rewrote it to be sane and I backported it to our > > tree. :-) ) So we do omit collation-related data, that was claimed in the > > code and elsewhere to be "collation rules", that's not being used by us. > > A standard ICU build contains localized collation rules in both source and > compiled form. The source form is needed to support an ICU API that lets > applications tailor the rules to their specific needs. ECMA-402 doesn’t > provide such an API, and I don’t think Mozilla will need it, so we’re using > the build flag ??? to get rid of the source form. The Collator implementation > uses the compiled form. > > Norbert > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
