Re: Prickliness of the "invalid byte code" stuff

[Stefan Monnier]

>> The files using this option are expected to be faster to load (because
>> we load a bit less into heap).
> There's also the effect on Emacs memory footprint, right?

Yes.

>> The downsides are:
>> - it doesn't work when the .elc files are compressed.
>> - it doesn't work when the .elc files are loaded via Tramp.
>> - If the .elc files is re-generated after the .elc file was loaded,
>>   calling functions from that file typically signal an error (such as
>>   "invalid byte code").
> The same problems happen with lazily loading doc strings, right?

Yes (at least for the third point (reload), not sure how the first two
points are affected by compression and access via Tramp).

> Or is that different in some way?

There are some qualitative differences:

- docstrings are only loaded in fairly specific circumstances (mostly
  C-h <foo>), whereas lazy loading of code can happen in the middle of
  arbitrary code execution, so an error there can be more troublesome.

- when lazy loading a docstring and we discover that the file has
  changed (which we admittedly don't always notice), the code currently
  is able to reload the .elc file to update the offset and try again.
  In contrast, for lazy loading of code, the code is currently unable to
  do that (this is the origin on this discussion: it could be fixed in
  the common cases, but last I looked at it, it'd require changes to the
  code which could be detrimental to the common case).

- when we don't notice that the file was modified (i.e. the offset is
  wrong, but it happens to point to a valid place), displaying the wrong
  docstring is just annoying, whereas loading the wrong bytecode can
  lead to much more severe problems.

>> A `grep byte-compile-dynamic: **/*.el` seems to indicate it's currently
>> used in 12 files bundled with Emacs.
> Any idea why those 12 use it?

I think in the 20th century, the performance difference could be
measured (at least in benchmarks, tho maybe also in actual use), but
I seriously doubt it makes a noticeable difference on machines of this
century (not sure if it's because of changes in hardware such as
available RAM or CPU speed, or because the growth of the rest of
Emacs dwarfs those effects, or what).


        Stefan