Startup: improve speed

[manuel-uberti]

Is there a way to prevent Mapping unicode blocks at every start of Emacs? It really slows down the startup.

I disabled many Keys in unicode-fonts-block-font-mapping, but still it takes 89.8 seconds to start.

If I close Emacs immediately after it is up and then start it again, it still takes 92.0 seconds.

Only way I am able to resolve this is by starting Emacs as daemon and connect to it with emacsclient.

[rolandwalker]

Hi!

Yes, if you install persistent-soft.el there is extensive caching, and startup time is negligible.

[manuel-uberti]

No luck. I added persistent-soft.el, required it, but still have an init time of 150.6 seconds when I start Emacs for the second time. I forgot to mention I am using latest Emacs trunk (built this morning). Could it be related to that?

[rolandwalker]

I'll definitely try the Emacs trunk to see if that's the problem.

persistent-soft.el has to be loaded first, or available to autoload, (which I'm sure you already know). Could you look in ~/.emacs.d/var/ to see if any cache files were written there?

The final cache product is actually Lisp code that can be evaluated. I've been intending to expose that somehow. Once created, if you know that your system hasn't changed, you can simply load the generated code.

The caches do take the Emacs version into account, so you can also try running a stable Emacs twice, to see if that shows the same symptom.

[manuel-uberti]

You're right. I have unicode-fonts (among other files) in ~/.emacs.d/var/pcache/.

[swsnr]

@rolandwalker @manuel-uberti I'm suffering from this issue as well. Persistence is not working anymore on Emacs trunk.

It used to work, though, even on trunk, until a week or two ago, and I do have another system with an older trunk build where it still works.

[manuel-uberti]

@lunaryorn only way I am able to solve this for now is using emacs --daemon and then emacsclient.

[rolandwalker]

@lunaryorn, thanks for the data point.

I downloaded a build after the initial report, which looks to be based on commit 16d91bc, and should be able to fix by the weekend.

The purpose of persistent-soft.el was to wrap differing versions of CEDET (including no CEDET) and fail gracefully when there is a problem: that is, to at least keep Emacs running. So we will tweak it to match the CEDET changes that seem to have occurred in trunk.

However, perhaps the design was unwise. It might be more dependable to just implement persistence in a clean standalone library.

[swsnr]

@rolandwalker Any progress on this?

[rolandwalker]

I should have something today.

[manuel-uberti]

@rolandwalker happy to hear that!

[rolandwalker]

The diagnosis was correct, but it looks like this was already addressed by pcache.el in https://github.com/sigma/pcache/commit/0b72b466e931a093d1c698177b555ccc9e8231fa . (persistent-soft depends on pcache depends on eieio).

While I can still exercise one bug in the persistent-soft.el test suite under trunk, it doesn't touch any of the libraries here.

So, upgrading pcache.el to 0.3.1 should solve the problem, and I am updating the dependencies for MELPA.

It might be nice in the future to give the user a clear message about cache failure. "Graceful failure" is a nice concept, but there is a great deal of caching going on here, and this library is essentially useless without that cache.

[manuel-uberti]

Grabbed your latest commit from MELPA. I already have pcache.el 0.3.1. First start: 166.5 seconds. Second start: 173.4 seconds.

Beside upgrading unicode-fonts and pcache.el do I need to do something else?

[rolandwalker]

Hm!

You could try removing the directory ~/.emacs.d/var/pcache/unicode-fonts/, but I suspect that won't change anything.

I'd like to know exactly which commit you are running from when we say "trunk": can you send the output of git rev-parse HEAD from the build directory? Or point me to the binary?

Lastly, it is good to doublecheck the output of: M-: pcache-version-constant RET (which should be "0.3") and/or check the output of

$ ls -ld ~/.emacs.d/elpa/pcache*

in case a library has been installed from both MELPA stable and unstable, after which the "unstable" variant is always loaded, even when older. (Has bitten me multiple times.)

I greatly appreciate you highlighting the issue, and thank you for any feedback you might have time to give. It is always preferable to resolve such incompatibilities before a new release arrives.

[manuel-uberti]

Deleting ~/.emacs.d/var/pcache/unicode-fonts/ made no difference. Here is the info you required:

git rev-parse HEAD
ed7005c0e974a43c9b63d6f5d8ef6bd4099ba449

ls -ld ~/.emacs.d/elpa/pcache*
drwxr-xr-x   2 manuel         manuel       4096 2015-02-23 20:10 /home/manuel/.emacs.d/elpa/pcache-20150125.1653/

Also, MELPA is setup like this in my init.el:

;; Add Melpa
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/"))
(package-initialize)

[manuel-uberti]

Grabbed latest persistent-soft.el from MELPA, but I still got this issue.

[rolandwalker]

Thanks! I can duplicate the issue again with commit ed7005c (dated 23 Feb).

Previously I was working with commit 16d91bc (dated 16 Feb). For 16d91bc, upgrading pcache was sufficient. For ed7005c it is not.

[manuel-uberti]

I see. I'm still at ed7005c, so if you need me to do further tests feel free to ask.

[swsnr]

@rolandwalker The issue still exists in 1903e25c17a0dce03710143659c0fa9e9c6d6494. Can we help you fix it? Currently it makes unicode-fonts barely useable for me…

[salehsaleh]

hi

[manuel-uberti]

Any news on this one?

[manuel-uberti]

Me and @lunaryorn are still waiting on this one. :)

[swsnr]

Seems that this issue is solved now. Just tried unicode-fonts again on a recent HEAD build, and caching works again.

[manuel-uberti]

@lunaryorn thanks for the update. I can confirm it works on my machine too (trunk build 59db430).