This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hi! Even with using -j$numprocs in make install_locales it takes very very long time to build all the locales (well, without -j$numprocs it takes longer than to build whole glibc), but the vast majority of LC_COLLATE and LC_CTYPE files is identical. localedef will hardlink them together, but after the costly computation; I believe LC_COLLATE and LC_CTYPE take far most of the time. E.g. I have 116 identical *.utf8/LC_CTYPE files and 79 *.utf8/LC_COLLATE files. I wonder, wouldn't it make sense to add some special option to localedef, with which user could specify a cache file. make install_locales would delete this cache file first, and for LC_COLLATE resp. LC_CTYPE (maybe for any category, but IMHO it makes sense only for those 2) which consists just of copy "something" token appart from comments would first search in this cache file (it can be a text file with path, locale category, the copy string and character map) if such locale category has been generated already. If yes, it would just hardlink (or copy if it failed) such file into the new locale subdir, otherwise it would normally compute it and at the end add a line into the cache file (with some locking, so that two localedef don't append over each other). Jakub
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |