GNU bug report logs - #23967
25.1.50; Slow compilation of ns-win.el

Previous Next

Full log

View this message in rfc822 format

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 23967 <at> debbugs.gnu.org
Subject: bug#23967: 25.1.50; Slow compilation of ns-win.el
Date: Wed, 13 Jul 2016 17:15:15 -0400

[Message part 1 (text/plain, inline)]

On Wed, Jul 13, 2016 at 10:55 AM, Eli Zaretskii <eliz <at> 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 (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.