unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: 50777@debbugs.gnu.org,
	"Stefan Monnier" <monnier@iro.umontreal.ca>,
	"Daniel Martín" <mardani29@yahoo.es>
Subject: bug#50777: Dropping EIEIO from xref (for performance)
Date: Sun, 26 Sep 2021 21:34:10 +0300	[thread overview]
Message-ID: <cf641429-d583-ea5e-a3db-a56df10359db@yandex.ru> (raw)
In-Reply-To: <1060904C-43A4-4981-9E29-5859AD9AB4A5@acm.org>

On 26.09.2021 11:51, Mattias Engdegård wrote:
> 26 sep. 2021 kl. 03.15 skrev Dmitry Gutov <dgutov@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.





  reply	other threads:[~2021-09-26 18:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24 13:28 bug#50777: Dropping EIEIO from xref (for performance) Dmitry Gutov
2021-09-24 13:35 ` Dmitry Gutov
2021-09-24 13:37 ` Dmitry Gutov
2021-09-24 14:49   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-24 15:32     ` Dmitry Gutov
2021-09-26  1:15       ` Dmitry Gutov
2021-09-26  8:51         ` Mattias Engdegård
2021-09-26 18:34           ` Dmitry Gutov [this message]
2021-09-24 15:12   ` Arthur Miller
2021-09-25  1:42   ` Lars Ingebrigtsen
2021-09-25  1:52     ` Dmitry Gutov
2021-09-25 14:07   ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-26  2:16     ` Dmitry Gutov
2021-09-30 21:10 ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cf641429-d583-ea5e-a3db-a56df10359db@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=50777@debbugs.gnu.org \
    --cc=mardani29@yahoo.es \
    --cc=mattiase@acm.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).