[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Install-time byte-compiling: Why bother?

Jonathan Walther writes:
> On Sat, 8 May 1999, Richard Kettlewell wrote:

>> 3.  A lot of the Emacs packages spend ages byte-compiling various
>> files during the install.  Given that the results might well never be
>> used this seems rather wasteful.  Also it's quite time-consuming, even
>> on a fast machine; I hate to think what it'd be like on a much slower
>> machine.
> I've never found it to take more than a few minutes.  Again, if you want to
> submit a patch to emacs so that packages are byte-compiled when they are
> first called, feel free.

Actually, I've just done some timings.

On one machine, a 233Mhz K6, I invoked Gnus in Xemacs20.  When the
byte-compiled .elc files were available, it took 12 seconds.  When
they weren't, and emacs had to byte-compile on the fly, it took 14

On another machine, this a 300Mhz K6-2, I invoked W3 in Xemacs20
(using lisp interaction mode to eliminate the wait for the user to
enter a URL).  In this case it was 10 seconds for .elc files, 15
seconds if it had to byte-compile the .el files themselves.  This was
to retrieve and render a 4Kbyte web page with no images/frames/etc,
retrieved via the local ethernet.

Now these are delays that you have to suffer once per Emacs session,
not each time you enter Gnus/view a web page/etc.  We're talking at
best a 30% improvement from those numbers.  My methods are hardly
scientific, I know - perhaps others can produce similar comparisons
for slower or faster machines.

What's the cost of install-time byte-compilation?  In my experience
it's an incredibly fragile process; see for example my recently
submitted bug report #37355.  Right now I don't have a correctly
installed emacs19 or emacs20 on lyonesse (which is one reasons why I
only used Xemacs20 above).

I suggest, therefore, that the install-time byte-compilation of elisp
files be either eliminated completely, or turned into an option, with
the default set to "off".


Reply to: