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

[Noam Postavsky]

On Wed, Jul 13, 2016 at 10:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.

I ran the profiler on a compilation of ucs-normalize.el and found 2
easy optimizations (ucs-normalize-block-compose-chars was using
with-temp-buffer in a loop, so I lifted the it out of the loop; using
regexp-opt-charset instead of regexp-opt saves some char-to-string
conversion, sorting, and duplicate deletion). The attached patch
brings the compilation down from 2.5 seconds to 0.8 seconds in my
normal running Emacs, and using the bootstrap-emacs command posted by
Lars (swapping ../lisp/international/ucs-normalize.el for
../lisp/term/ns-win.el) from 1m30s to 7s.

>  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.

Could we call `byte-compile' on the byte-compiler functions after loading them?

ucs-normalize.el.diff
Description: Text document