How to load recentf only after opening/saving a file for the first time?

[Sebastien Vauban]

Hello,

Always with the same performance-oriented analysis of my .emacs file, I'm
trying to require recentf not during the startup, but later, as soon as it's
really needed. Not that heavy, but every little flow participate in the big
ocean...

I guess the right time to require recentf is the first time we open or save a
file.

Though, for opening, the only hook available is run after find-file, so too
late to save the first opened file, it seems.

What would be a correct way to delay the require of recentf?

Best regards,
Seb

--
Sebastien Vauban

[Drew Adams]

> I guess the right time to require recentf is the first time
> we open or save a file.
> Though, for opening, the only hook available is run after
> find-file, so too late to save the first opened file, it seems.
> What would be a correct way to delay the require of recentf?

So you want recentf to be loaded when you use any command that might visit a
file? There is no way to know (absolutely) what all those commands might be.

You could certainly use `find-file-hook' to load recentf _after_ the first file
visit. Or `(before|after)-save-hook' to do so before/after the first save.

Of if you limit yourself to a known set of file-visiting commands then you could
do what you want on `pre-command-hook', testing for those commands. But that
seems a bit heavy-handed.

Or if you want this only for some particular command (e.g. `file-file') that you
use often, then you could define your own version (e.g. `my-find-file') that
does (require 'recentf nil t) as part of the `interactive' spec.

All that said, I cannot imagine using Emacs interactively without ever using a
file-visiting command! So I cannot imagine why, if you want recentf for such
commands, you do not just load recentf from the get-go, in your .emacs.

[Sebastien Vauban]

Hi Drew,

"Drew Adams" wrote:
>> I guess the right time to require recentf is the first time
>> we open or save a file.
>> Though, for opening, the only hook available is run after
>> find-file, so too late to save the first opened file, it seems.
>> What would be a correct way to delay the require of recentf?
>
> So you want recentf to be loaded when you use any command that might visit a
> file? There is no way to know (absolutely) what all those commands might be.
>
> You could certainly use `find-file-hook' to load recentf _after_ the first file
> visit. Or `(before|after)-save-hook' to do so before/after the first save.
>
> Of if you limit yourself to a known set of file-visiting commands then you could
> do what you want on `pre-command-hook', testing for those commands. But that
> seems a bit heavy-handed.
>
> Or if you want this only for some particular command (e.g. `file-file') that you
> use often, then you could define your own version (e.g. `my-find-file') that
> does (require 'recentf nil t) as part of the `interactive' spec.

OK. The time seems much more complex than expected.

> All that said, I cannot imagine using Emacs interactively without ever using a
> file-visiting command!

I don't either!

> So I cannot imagine why, if you want recentf for such commands, you do not
> just load recentf from the get-go, in your .emacs.

The fact is that Emacs (RC 24.2 on Windows) takes around 25 seconds to load my
(huge, yes) .emacs file (378 KB, ~10 KLOC from which a third is white lines,
and another one is comment lines).

Loading Org mode takes another minute or so, with 50 agenda files.

That's really too much. That's why I'm trying to refactor my .emacs file to
try to see what takes time. I'm trying to autoload as much as possible, and to
delay the `require' calls to some known point in time.

That's why I was wondering how to do that for recentf. But I've the same
question for vc, for example, which consumes 3 seconds:

--8<---------------cut here---------------start------------->8---
(info) +-> Requiring `vc'...
(info) +-> Requiring `vc-hooks'... already loaded
(info) +-> Requiring `vc-dispatcher'... c:/Program Files/Emacs-24.2/lisp/vc/vc-dispatcher.elc (loaded in 0.33 s)
(info) +-> Requiring `ediff'...
(info) +-> Requiring `ediff-init'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-init.elc (loaded in 0.33 s)
(info) +-> Requiring `ediff-mult'...
(info) +-> Requiring `ediff-init'... already loaded
(info) +-> Requiring `ediff-mult'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-mult.elc (loaded in 0.31 s)
(info) +-> Requiring `ediff-util'...
(info) +-> Requiring `ediff-init'... already loaded
(info) +-> Requiring `ediff-help'...
(info) +-> Requiring `ediff-init'... already loaded
(info) +-> Requiring `ediff-help'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-help.elc (loaded in 0.28 s)
(info) +-> Requiring `ediff-mult'... already loaded
(info) +-> Requiring `ediff-wind'...
(info) +-> Requiring `ediff-init'... already loaded
(info) +-> Requiring `ediff-wind'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-wind.elc (loaded in 0.28 s)
(info) +-> Requiring `ediff-diff'...
(info) +-> Requiring `ediff-init'... already loaded
(info) +-> Requiring `ediff-diff'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-diff.elc (loaded in 0.28 s)
(info) +-> Requiring `ediff-merg'...
(info) +-> Requiring `ediff-init'... already loaded
(info) +-> Requiring `ediff-merg'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-merg.elc (loaded in 0.28 s)
(info) +-> Requiring `ediff-util'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-util.elc (loaded in 1.45 s)
(info) +-> Requiring `ediff'... c:/Program Files/Emacs-24.2/lisp/vc/ediff.elc (loaded in 2.39 s)
(info) +-> Requiring `vc'... c:/Program Files/Emacs-24.2/lisp/vc/vc.elc (loaded in 3.00 s)
--8<---------------cut here---------------end--------------->8---

I don't know if that will ever be feasible, but I'd love to have Emacs started
in 5 seconds, and Org in not much more.

[Drew Adams]

> The fact is that Emacs (RC 24.2 on Windows) takes around 25
> seconds to load my (huge, yes) .emacs file (378 KB, ~10 KLOC
> from which a third is white lines, and another one is comment lines).
> Loading Org mode takes another minute or so, with 50 agenda files.
>
> That's really too much. That's why I'm trying to refactor my
> .emacs file to try to see what takes time. I'm trying to
> autoload as much as possible, and to delay the `require' calls

I understand. And that's a good approach. As you know, you can also use
`eval-after-load' to avoid doing some stuff unnecessarily.

As with any performance problem, start by attacking the biggest hogs. It sounds
like your 50 Org-mode agenda files constitute 2/3 of your performance problem at
the moment, so perhaps start there.

Do you really need to load all of your Org agenda files? Do they need to be so
big/slow? Does Org mode provide any constructs that might alleviate some of
this penalty?

I don't have answers for you, sorry. Except for this obvious one: try starting
Emacs less often and keeping your Emacs sessions open longer.

Oh, and of course byte-compile the code you load. (You mention whitespace lines
and commented lines, but those are irrelevant for byte-compiled code.)

And maybe try profiling code for the worst parts of your problem. Perhaps
you've hit a bug or two, or perhaps you've found an opportunity for some library
to be improved wrt load performance.

[Sebastien Vauban]

Hello Drew,

"Drew Adams" wrote:
> And maybe try profiling code for the worst parts of your problem. Perhaps
> you've hit a bug or two, or perhaps you've found an opportunity for some library
> to be improved wrt load performance.

I did not give, last time, the time needed to load `recentf'. Here it is
(1.72 s):

--8<---------------cut here---------------start------------->8---
(info) +-> Requiring `recentf'...
(info) +-> Requiring `easymenu'... c:/Program Files/Emacs-24.2/lisp/emacs-lisp/easymenu.elc (loaded in 0.33 s)
(info) +-> Requiring `tree-widget'...
(info) +-> Requiring `wid-edit'... c:/Program Files/Emacs-24.2/lisp/wid-edit.elc (loaded in 0.44 s)
(info) +-> Requiring `tree-widget'... c:/Program Files/Emacs-24.2/lisp/tree-widget.elc (loaded in 1.02 s)
(info) +-> Requiring `timer'... already loaded
(info) +-> Requiring `recentf'... c:/Program Files/Emacs-24.2/lisp/recentf.elc (loaded in 1.72 s)
--8<---------------cut here---------------end--------------->8---

About `vc' (3.00 s) -- which I need at startup time (?) for displaying an icon
in the modeline ("Unmodified-according-to-VC" buffer vs modified buffer) --, I
think it requires much more than needed (`ediff', for example, is not
necessary at startup time)...

... but I can't do anything about it, right, as it is hard-coded that way in
`vc.el' (which I need for the vc-icon in every loaded file).

Same for the (very) nice-to-have `dired+' which requires `ediff-util', hence a
lot more at the end (4.20 s in total):

--8<---------------cut here---------------start------------->8---
(info) +-> Requiring `dired+'...
(info) +-> Requiring `easymenu'... already loaded
(info) +-> Requiring `dired'... already loaded
(info) +-> Requiring `dired-aux'...
(info) +-> Requiring `dired'... already loaded
(info) +-> Requiring `dired-aux'... c:/Program Files/Emacs-24.2/lisp/dired-aux.elc (loaded in 0.25 s)

(info) +-> Requiring `ediff-util'...

(info) +-> Requiring `ediff-init'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-init.elc (loaded in 0.27 s)

(info) +-> Requiring `ediff-help'...
(info) +-> Requiring `ediff-init'... already loaded
(info) +-> Requiring `ediff-help'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-help.elc (loaded in 0.28 s)
(info) +-> Requiring `ediff-mult'...

(info) +-> Requiring `ediff-init'... already loaded

(info) +-> Requiring `ediff-mult'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-mult.elc (loaded in 0.28 s)

(info) +-> Requiring `ediff-wind'...
(info) +-> Requiring `ediff-init'... already loaded

(info) +-> Requiring `ediff-wind'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-wind.elc (loaded in 0.27 s)

(info) +-> Requiring `ediff-diff'...
(info) +-> Requiring `ediff-init'... already loaded

(info) +-> Requiring `ediff-diff'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-diff.elc (loaded in 0.25 s)

(info) +-> Requiring `ediff-merg'...
(info) +-> Requiring `ediff-init'... already loaded

(info) +-> Requiring `ediff-merg'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-merg.elc (loaded in 0.23 s)
(info) +-> Requiring `ediff-util'... c:/Program Files/Emacs-24.2/lisp/vc/ediff-util.elc (loaded in 1.88 s)
(info) +-> Requiring `dired-x'...
(info) +-> Requiring `dired'... already loaded
(info) +-> Requiring `easymenu'... already loaded
(info) +-> Requiring `dired-x'... c:/Program Files/Emacs-24.2/lisp/dired-x.elc (loaded in 0.47 s)
(info) +-> Requiring `misc-fns'... nil (loaded in 0.30 s)
(info) +-> Requiring `w32-browser'... nil (loaded in 0.25 s)
(info) +-> Requiring `dired+'... already loaded
(info) +-> Requiring `bookmark+'... nil (loaded in 0.25 s)
(info) +-> Requiring `bookmark+'... nil (loaded in 0.25 s)
(info) +-> Requiring `bookmark+'... nil (loaded in 0.23 s)
(info) +-> Requiring `help-mode'... already loaded
(info) +-> Requiring `dired+'... d:/home/sva/Downloads/emacs/site-lisp/dired+.el (loaded in 4.20 s)
--8<---------------cut here---------------end--------------->8---

Any way to lighten this?

OK, maybe I should load `dired+' in an eval-after-load "dired" (if that one is
not loaded on its own, by Emacs?)... I'll try.

[Stefan Monnier]

> (info) +-> Requiring `vc'...

[...]

> (info) +-> Requiring `ediff'...

Yuck! That's a bug, indeed, please report it.


Stefan

[Drew Adams]

> Any way to lighten this?

Dunno. See Stefan's reply about filing an Emacs bug report.

> OK, maybe I should load `dired+' in an eval-after-load
> "dired" (if that one is not loaded on its own, by Emacs?)

No, load Dired+ by using (require 'dired+). It will load the standard Dired
files.