[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: On elisp running native

From: arthur miller
Subject: RE: On elisp running native
Date: Thu, 2 Jan 2020 07:55:27 +0000

A question:

Would it be possible to lump all compiled functions into one .so file per package?

I have tested your branch after update2, haven't had time to test after the last update. I didn't see any speedup on load time, either with -Q flag, or when I loaded my init files and packages. I have complied all elpa packages to eln, including my custom lisp and init file (whatever was compilable).

I guess since there is one .eln per .el file, there is lots of disk access. Same for byte code and pure lisp. Maybe the init time is dominated by file access, rather then the processing those files.

Could it maybe be possible to create one .so per package si that all functions from corresponding eln files is that .so? It could drastically reduce number of file access at load time. I don't know if it is possible. 

Skickat från min Samsung Galaxy-smartphone.

-------- Originalmeddelande --------
Från: Andrea Corallo <address@hidden>
Datum: 2020-01-01 19:42 (GMT+01:00)
Till: Stefan Monnier <address@hidden>
Kopia: Eli Zaretskii <address@hidden>, address@hidden
Ämne: Re: On elisp running native

Stefan Monnier <address@hidden> writes:

> I think the focus should be on:
> - making it work everywhere
> - making it easy/convenient to use (e.g. even if you share your $HOME between
>   different architectures or even different OSes as well as different
>   versions of Emacs)

I think the natural action would be to move the eln in the build
directory (as these are in fact compiled).  Unfortunately this would not
work with the elpa packages...  The other option would be to add a
suffix to the the eln file but is not nice at all.  Any idea?

Consider that now the situation is pretty bad because eln are likely not
to be compatible even from different builds on the same codebase with
different configure parameters.

> As far as I'm concerned, support for a nil value of lexical-binding is
> a non-goal (it should still work, of course, e.g. by using the
> bytecode): the dynbind version of Elisp is a legacy language and it's
> better to update the code to lexbind than to try and make that legacy
> code run faster.

Good I agree, and even if not that hard would be something more to care


reply via email to

[Prev in Thread] Current Thread [Next in Thread]