GNU bug report logs - #50777
Dropping EIEIO from xref (for performance)

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 50777 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>, Daniel Martín <mardani29 <at> yahoo.es>
Subject: bug#50777: Dropping EIEIO from xref (for performance)
Date: Sun, 26 Sep 2021 21:34:10 +0300

On 26.09.2021 11:51, Mattias Engdegård wrote:
> 26 sep. 2021 kl. 03.15 skrev Dmitry Gutov <dgutov <at> yandex.ru>:
> 
>>   (void-function make-closure)
>>
>> was a much bigger problem. This is apparently how lambdas are compiled now.
> 
> There are no circumstances under which Emacs 28 bytecode is guaranteed to work in earlier Emacs versions: there is backward but no forward compatibility. For example, any code using `with-temp-buffer` won't work, nor as you noticed anything creating closures.

It's all right. Sometimes the compiled code is compatible, but sometimes 
it's not. We could introduce format versions, maybe. Though it's hard to 
draw the line because it's probably not the byte-code format itself that 
changed, but simply certain representations of primitives.

I was just saying that pushing that change now might allow us to stop 
worrying about a particular incompatibility. But we'll probably disable 
inlining for xref-item accessors anyway, to allow a similar migration to 
another underlying data format in the future. Just in case.

> This is unavoidable and the alternative would be much worse, but it's sometimes annoying when testing code with different versions and (in particular) installing packages using a new version and then using an old one.

True.

> Could we arrange the .el file to be used if the .elc is built with a newer Emacs version? (Perversely, it would make some inlined functions faster...)

Sometimes it will be faster, but sometimes much slower (2x or more). I'm 
not sure what's the best solution here. Maybe loading .el files *and* 
nagging the user once per session to recompile their packages could work.

> An alternative would be to segregate installed packages by (major) version, so that ~/.emacs.d/ has separate installations for Emacs 26, 27, 28 and so on.

Sounds clunky, but maybe it's the right choice. Or maybe move only the 
compiled files to a separate directory (or directories), and version 
them by byte-code format. Or major Emacs version.

Previous Next

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