6

Why wouldn't I byte-compile all the packages I install? Is there some consequence of byte-compile making it a decision to think about?

Suraj
  • 35,905
  • 47
  • 139
  • 250

3 Answers3

3

One negative is that you can't debug byte compiled code. On the flip side, once the code is production ready, in theory you wouldn't need that (and you could reinstall it w/o byte compilation if you needed to)

geoffjentry
  • 4,674
  • 3
  • 31
  • 37
  • I'm not in a position to verify this statement at the moment, but that's my understanding. – geoffjentry Dec 01 '11 at 15:43
  • You might be right - I was thinking of this post: https://stat.ethz.ch/pipermail/r-devel/2011-July/061441.html but re-reading it they're specifically talking about teh debug package and not debug() – geoffjentry Dec 02 '11 at 00:55
  • So it seems that there is no major downside for the average R user who isn't loading R in a debugger. – Suraj Dec 03 '11 at 15:53
1

In R version 2.14, a major downside of byte-compiling was that it could slow down certain functions. Another two downsides were increased package size and installation.

For the current version of R (3.3.X), I have yet to find a downside for byte-compiling.

csgillespie
  • 59,189
  • 14
  • 150
  • 185
1

Currently the development version of R already byte-compiles all packages by default, so one does not have to turn byte-compilation on in the DESCRIPTION file. A related answer mentions overheads of byte-compilation - it is possible but rare that byte-compilation would harm performance (it can happen when code is loaded that will never be used - the JIT won't compile it, but the loader still loads it; hopefully this can be addressed in the future).

browser() and debugging with the byte-compiled code works, from the user perspective, the same way as with non-compiled code. Internally the debugger runs on the AST of the program (so bypassing the byte-code), but this is not visible to the user.

Tomas Kalibera
  • 1,061
  • 9
  • 13