3

Do you have examples of packages that benefit substantially from byte-compilation?

I would prefer to avoid byte-compiling files when it is not necessary, in particular when installing hundreds of packages, since it takes significantly longer to byte-compile. A comment in the package.el source even suggests that "Compilation should be done as a separate, optional, step."

The Byte Compiling section of the Emacs manual states: "As a practical matter, for most things you might do to customize or extend Emacs, you do not need to byte compile".

The Elisp manual includes an example of the performance of byte-compiled code: "In this example, the interpreted code required 10 seconds to run, whereas the byte-compiled code required less than 4 seconds. These results are representative, but actual results may vary."

EDIT: Where "substantially" means a measurable difference like the example above in the running time of a package feature, or a measure of the latency of UI interaction.

Improve this question
6
  • This question is a bit too broad, IMO. You already acknowledge that the manual tells you that for most purposes you do not need to byte-compile. That answers the question of whether you ever need to byte-compile. Asking for particular packages where byte-compiling is a "substantial benefit" is too broad, and primarily opinion-based: define "substantially". This is not a question that fits well with a Q&A site. The simple answer is that you never need to byte-compile. Where & when is answered by whenever/wherever you want to - you decide whether something is too slow - for your context.
    – Drew
    Aug 23, 2016 at 14:53
  • @Drew I've added a definition of "substantially" so it is hopefully clearer that I am asking for a real-life package example with some measurable speed difference like the contrived elisp manual example included in my original post.
    – aculich
    Aug 23, 2016 at 15:12
  • Anything that uses cl-lib (aka cl) package will greatly benefit from bytecompiling it. In general, anything that has many macros in it will benefit a lot. For some code the behavior is different, or only available if compiling (say, if some code is wrapped in when-compile macro and similar.
    – wvxvw
    Aug 23, 2016 at 19:23
  • 1
    Asking for a measurable difference leaves only one answer to give: Go ahead and measure yourself :)
    – user227
    Aug 24, 2016 at 17:30
  • @wvxvw There should be no difference in behaviour. Emacs evaluates eval-when-compile at load time for non-compiled code. Likewise I do not think that macros still make a difference in recent Emacs versions which eagerly expand all macros at load time.
    – user227
    Aug 24, 2016 at 17:33

2 Answers 2

Reset to default
5

Before the advent of eager (load-time) macro expansion, I would have said this was crazy talk, and told you to forget the idea and compile everything as usual.

Maybe it's somewhat less crazy now that macros are generally not expanded upon each evaluation -- but compiled elisp is still going to be faster (by varying margins) for pretty much everything, and elisp is not a fast language; so I just can't imagine why you'd pass up the long-term benefits of faster execution for the short-term benefits on the occasions when you install "hundreds of packages".

Admittedly, I don't know what your scenario is when you're doing that on a regular(?!) basis, so it's tricky to establish what the cost-vs-benefit might be here.

I'm guessing that you have a bare-bones Emacs config which fetches and installs these hundreds of packages the first time you run it. If you simply keep all the packages in your config (in version control, or however you're managing it) then this would be a non-issue, and you'd get the best of both worlds -- much faster installation (no need to fetch or compile anything), and you still have byte-compiled code.

Edit:

A pretty trivial test is to remove all *.elc files from your config, then start Emacs, use it for a while (making use of as many features as possible), and decide whether it's acceptable or not.

find ~/.emacs.d/ -type f -name "*.elc" -delete
Improve this answer
3
  • 1
    Interesting points, but your post does not directly answer the question: what example packages benefit substantially from byte-compilation? Not sure why it is crazy talk to want to "avoid byte-compiling files when it is not necessary"? Definitely compile when it is necessary. Otherwise, avoid hassles and things that can go wrong with byte-compiled files-- a whole class of problems disappear, for a potential (mostly imperceptible) speed penalty. When the speed penalty becomes noticeable, then it may be a good to consider byte-compiling.
    – aculich
    Aug 23, 2016 at 14:38
  • As for my use case, I have a couple different ones, but one (admittedly probably a little crazy) is to cask install all of the available non-conflicting packages (several thousand) from MELPA, and regularly keep the local installation up-to-date.
    – aculich
    Aug 23, 2016 at 14:44
  • Agreed, I haven't answered the direct question -- I don't have any offhand examples, and I don't want to do any benchmarking for this. I just posted my answer because I suspected there was a better solution to the problem (which I had incorrectly imagined was a more typical use-case than you've outlined!)
    – phils
    Aug 23, 2016 at 15:08
4

js2-mode benefits substantially from byte compilation because it does heavy computing to semantically analyze the Javascript code.

Other major modes use regular expression. byte compilation does not matter for them.

Usually you don't need care about byte compilation because plugins don't do heavy computing at all.

A plugin is just a Emacs Lisp file. It has no difference with your dot Emacs file. So it's often the waste of time to compile your dot Emacs file

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.