13

Configuration:

  • One system (same hardware)
  • OS Windows 10
  • OS Ubuntu 15.10
  • Emacs 25.0.1 with 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 10: I symlinked the dot-emacs and .emacs.d from the home folder in Windows to the locations in Dropbox.

On Linux/Ubuntu 15.10: 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 start.

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.

The following things are identical on the operating system (Windows 10 and Xubuntu 15.10):

  • Emacs software, version 25.0.1
  • Configuration files (.emacs.d)
  • Harddisk (all files inside `.emacs.d) and both OS'es are on same SSD).
  • Hardware

The only difference:

  • Compiled Emacs for Windows or Linux respectively is running on Windows or Linux platform. That's the only difference.

I'm struggling to understand why Emacs have noticeably shorter startup time on Ubuntu/Xubuntu than Windows.

  • 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
20

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

  • 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
  • 1
    @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
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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