bug#23967: 25.1.50; Slow compilation of ns-win.el

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 13 Jul 2016 14:19:21 +0200
> 
> I've been looking slightly at why "make -j8" isn't as parallel as you'd
> expect, and in my tests it's because one single .el compilation job is
> weirdly slow.
> 
> To test:
> 
> If I say "make bootstrap" (to get rid of everything) and then halt the
> compilation after it's made bootstrap-emacs
> 
> [larsi@stories ~/src/emacs/trunk/lisp]$ time ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval "(setq load-prefer-newer t)" -l bytecomp -f byte-compile-refresh-preloaded -f batch-byte-compile ../lisp/term/ns-win.el
> 
> real    0m44.097s
> user    0m44.156s
> sys     0m0.012s
> 
> 44 seconds to compile it.  From stracing, the thing it says before it
> ... doesn't say anything for half a minute is:
> 
> readlinkat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/international/uni-decomposition.el", 0x7fff42af6240, 1024) = -1 EINVAL (Invalid argument)
> 
> So...  er...  it has something to do with Unicode?
> 
> This may not be a bug or anything, but it's perhaps something that
> should be looked at to speed up the initial Emacs compilation.

This is a known problem.  The culprit is ucs-normalize.el
(uni-decomposition is loaded when ucs-normalize is compiled).  It
takes a long time to compile even with Emacs that already has the
byte-compiled byte-compiler loaded into it.  When compiling
ucs-normalize with an interpreted byte-compiler, it takes ages (11 min
on my Core i7).  And since ucs-normalize is now preloaded on OS X, we
compile it with the interpreted byte-compiler, as we do with any other
file that is preloaded on _some_ platform.

Patches to solve this conundrum in some way are welcome.