up vote 12 down vote favorite
4

Specs:

  • Windows 10
  • Xubuntu 15.10
  • Same hardware, Emacs 25.0.1 GUI

I have one dot-emacs file and everything in my .emacs.d folder (the packages also are located in .emacs.d). All of these files are located in one Dropbox folder.

On Windows: I symlinked the dot-emacs and .emacs.d from the home folder in Windows to the locations in Dropbox.

On Linux: I have also symlinked the dot-emacs and .emacs.d from my Ubuntu home folder (/home/user/ to the locations in Dropbox.

So all files related to Emacs, are stored in one Dropbox folder across various operation systems.

Windows and Linux are running as dual boot on same disk, so also same hardware.

When I start Emacs on Windows, it takes 7.4 seconds to boot up.

When I start Emacs on Linux, it takes only 2.3 seconds to start.

This is both with the Emacs with graphical GUI and version 25.05. Both operating systems are located on same computer on same SSD drive. So it's also the same hardware.

Same:

  • Emacs 25.0.1
  • Init config files
  • Harddisk (both files and OS'es are on same SSD).
  • Hardware

Difference:

  • It's running on Windows or Linux platform. That's only the difference.

I'm struggling to understand why Emacs have noticeably shorter startup time on Ubuntu than Windows. Anyone knows the answer?

share|improve this question
  • 2
    You forgot to mention what build this is. Also, you should be comparing the startup times of a bare Emacs session with emacs -Q. – wasamasa Nov 1 '15 at 11:36
  • I need the (message emacs-init-time) to measure the startup time. This is not bounded to a function as far as I know. So how could I measure it with emacs -Q then? – ReneFroger Nov 1 '15 at 19:32
  • 1
    M-x emacs-init-time RET – giordano Nov 2 '15 at 1:03
  • 1
    I see this problem too.. my emacs takes 5-6 seconds to start on Linux, but up to a minute on Windows. Thankfully, Windows is not my primary OS at work. – Kaushal Modi Nov 5 '15 at 16:47
  • @ReneFroger runemacs -Q -f emacs-init-time will echo the time once init completes. For reference it takes 0.9s on Win7 for me (but ~20-25s with full init). And most of that actually is due to org (I haven't quite figured out how to bypass that). – Jonathan Leech-Pepin Nov 5 '15 at 17:40
up vote 18 down vote

Op-ed: Windows is just slow.

I regularly use Emacs on both Windows (Cygwin and native) and GNU/Linux (Arch), and I've noticed this as well. I believe the answer is that Linux is just plain faster than Windows in a lot of areas, most notably in file system operations1 and threading/forking operations2.

I think the difference in performance is most noticeably exemplified when using git, and especially Magit (since it runs quite a few commands for its status buffer). Git is horrendously slow on Windows. It's so slow, in fact, that I often edit code on Windows in my Dropbox folder, wait for it to be synced to my Linux VPS, and then use Magit via SSH, instead of simply using it on Windows.

Doing time git status on the Emacs master branch takes an average 0.025 seconds on Arch for me. On Windows (native), it takes 0.075-0.100 seconds, Windows (cygwin) 0.200 seconds. That may not seem like much, but that means it's 3-4x slower on Windows.

I should also note that certain anti-virus software (McAfee, in particular) can cause massive slowdowns. With McAfee's On-Access Scanner enabled, things are a noticeably slower for me. Cygwin's git status can take up to 2 minutes! Only after turning it off do I get the times I stated above.

Aside: I just found the variable magit-refresh-verbose, which times the status refreshes. Here are some times for a refresh of the magit-status buffer on the Emacs master branch:

Windows (native)

GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570
Magit 20151028.1649, Git 2.6.1.windows.1, Emacs 24.5.1
Refreshing buffer `*magit: emacs'...done (9.317s)
Refreshing buffer `*magit: emacs'...done (9.318s)
Refreshing buffer `*magit: emacs'...done (9.357s)

Windows (cygwin)

GNU Emacs 25.0.50.1 (i686-pc-cygwin) of 2015-07-29 on NAND-LT
Magit 20151015.22, Git 2.5.0.234.gefc8a62, Emacs 25.0.50.1
Refreshing buffer `*magit: emacs'...done (4.609s)
Refreshing buffer `*magit: emacs'...done (4.720s)
Refreshing buffer `*magit: emacs'...done (4.626s)

GNU/Linux (Arch, worse hardware, VPS)

GNU Emacs 25.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.2) of 2015-10-26
Magit 20151028.1649, Git 2.6.2, Emacs 25.0.50
Refreshing buffer ‘*magit: emacs’...done (0.517s)
Refreshing buffer ‘*magit: emacs’...done (0.507s)
Refreshing buffer ‘*magit: emacs’...done (0.523s)

Cygwin's faster speed surprised me.

  1. http://www.slideshare.net/PrincipledTechnologies/comparing-file-system-performance-red-hat-enterprise-linux-6-vs-microsoft-windows-server-2012

  2. https://stackoverflow.com/questions/12878980/speed-performance-of-a-qt-program-windows-vs-linux

share|improve this answer
  • Have you tried to add the path for git-related commands to exec-path? (stackoverflow.com/questions/16884377/…) In my case it improved the speed significantly. – joon Nov 5 '15 at 16:33
  • @joon Yes, all the relevant paths are already in my exec-path. – nanny Nov 5 '15 at 16:37
  • I see - I should test this in a linux box as well. Thanks! – joon Nov 5 '15 at 16:38
  • @joon No problem. If you find a way to speed this up on Windows, please let me know. It's really a pain. – nanny Nov 5 '15 at 16:39
  • I don't see any difference between cygwin and native speeds, it looks like you use different version of Emacs and magit for each, perhaps that's where the difference comes from. – npostavs Nov 5 '15 at 23:29
up vote 1 down vote

Maybe you can try to setup emacs-server so you can have a better experience. Using this approach or running emacs as a daemon you can just use emacsclient to start new windows not loading another emacs instance. It is a nice approach. I have not tested it in Windows but here is link that explains how to use it. I hope it helps you man.

Emacs Server

share|improve this answer

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.