unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: wavexx@thregr.org, emacs-devel@gnu.org
Subject: Re: native-comp write path?
Date: Sat, 12 Feb 2022 21:12:01 +0200	[thread overview]
Message-ID: <83v8xjrjb2.fsf@gnu.org> (raw)
In-Reply-To: <jwv35kootpa.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Sat, 12 Feb 2022 12:59:08 -0500)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Yuri D'Elia <wavexx@thregr.org>,  emacs-devel@gnu.org
> Date: Sat, 12 Feb 2022 12:59:08 -0500
> 
> >> I'd like to move the directory inside the XDG_CACHE hierarchy
> > IMO, this is a mistake: the eln-cache is supposed to be more
> > persistent than XDG_CACHE, and even more than the entire XDG
> > hierarchy.  It isn't really a "cache" in the XDG sense.
> 
> Really?  I thought the main defining feature of "cache" is that any of
> those files can be thrown away an the system will work as well (tho
> potentially a bit less efficiently) and the files will/can be
> transparently re-generated if/when needed.
> 
> The files in eln-cache seem to fit the description.

The *.eln files don't need to be updated as long as you don't modify
the corresponding *.el files.  This means that, for an Emacs built and
installed using the default procedure, the eln-cache will quickly fill
up with compiled *.el files from the Emacs distribution that you
frequently use.  If those *.eln files are removed, Emacs will
recompile them upon next startup, which might take a few minutes
during which Emacs will be more sluggish than usually (because JIT
native compilation by default uses half of the system's execution
units).

If you don't care about this, maybe it's okay to move the *.eln files
to the XDG cache.  But you need to understand the affects of this.

> Or is XDG's cache not expected to survive a login session?

I think it can disappear when you log off.  Which is also something to
keep in mind: your Emacs will compile the same files time and again
each login.



  reply	other threads:[~2022-02-12 19:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-12 13:38 native-comp write path? Yuri D'Elia
2022-02-12 14:14 ` Yuri D'Elia
2022-02-12 17:51 ` Eli Zaretskii
2022-02-12 17:59   ` Stefan Monnier
2022-02-12 19:12     ` Eli Zaretskii [this message]
2022-02-12 19:40       ` Stefan Monnier
2022-02-12 21:18       ` Yuri D'Elia

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=83v8xjrjb2.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=wavexx@thregr.org \
    /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).