Installing Windows 64 bit for Windows 7 is currently a massive pain Where is official 64-bit Emacs for Windows? (The manual said there is!) because although there are many roque cuts, GNU are not distributing those binaries for one reason or another.

One must compile their own binaries using the lengthy instructions at https://github.com/emacs-mirror/emacs/blob/emacs-25/nt/INSTALL.W64 or trust one of the many unofficial builds.

Does anybody have any hard evidence that 64 bit Emacs is faster than 32 bit running on 64 bit Windows 7?

Additionally, I use a few external applications such as exuberant ctags, aspell. Does anybody have any evidence of performance benefits to creating 64 bit versions of these applications?

  • See also -- How to build Emacs master branch (aka trunk) on MS-Windows -- emacs.stackexchange.com/questions/16971/… -- bburns.km recently posted a walk-through for Emacs 64-bit building. Inasmuch as there is now a clear and concise "step 1, 2, 3", it's not really a massive pain (in my opinion) to make your own build. Once you have the initial setup (i.e., the building environment), building Emacs is a breeze.
    – lawlist
    Jan 9, 2016 at 16:29
  • 1
    @lawlist ok thanks, but that's not really what I'm asking. I already know how to build emacs on Windows (I actually referenced the same docs that your link points to)
    – fommil
    Jan 9, 2016 at 17:05
  • Note, that there are 64-bit binary builds: emacsbinw64.sourceforge.net The speed of the x64 emacs is not so much of concern for me. It is much more the file size. I often have to deal with automatically generated text files from the global symbolic analysis of SimulationX. For big models these files can grow big (e.g., 500MB). This is approximately the limit for the 32-bit version of emacs. You get fast the message memory out for such files. This is not an answer -- just a comment!
    – Tobias
    Jan 9, 2016 at 21:25
  • @Tobias I know how to get/build 64 bit Windows Emacs. I'm specifically asking about performance in this question.
    – fommil
    Jan 9, 2016 at 22:49
  • It could be a bit slower due to the larger pointer size, but setting up the build environment is simpler, so it's a trade-off in that regard. It would be interesting to compare startup times for the two versions though, and any other slow operations. Jan 10, 2016 at 16:57

1 Answer 1


I did a couple of tests using Emacs 24.5 with the 32-bit build provided by GNU Emacs and the 64-bit build provided by Emacs-w64 - I thought the 64-bit build would be a little slower due to the larger pointer size but the differences were pretty negligible for ~20 second processes.

Then at Tobias's suggestion, I tested loading an .org file, and the 64-bit build was about 20% slower.

All times in seconds

| Test                     | 32-bit | 64-bit | Result     |
| Startup a 200kb init.el  |   19.1 |   19.0 |            |
|                          |   19.4 |   18.9 |            |
|                          |   19.3 |   19.3 |            |
| average                  |   19.3 |   19.1 | same       |
| Open a 220mb binary file |   19.6 |   19.4 |            |
|                          |   18.4 |   19.5 |            |
|                          |   18.9 |   18.9 |            |
| average                  |   19.0 |   19.3 | same       |
| Open a 10mb .org file    |  108.0 |  124.7 |            |
|                          |  105.6 |  128.4 |            |
|                          |  113.4 |  136.9 |            |
| average                  |  109.0 |  130.0 | 19% slower |

(note that it's just a coincedence that the first two tests have similar times)

The test script:

;; startup time with 200kb init.el
(message (emacs-init-time))

;; test file load times
(require 'benchmark)
(message "%f" (benchmark-elapse 
  ;;(find-file "c:/apps/emacs/bin/emacsclient.exe") ; 1mb file
  ;;(find-file "c:/users/bburns/downloads/Core-current.iso") ; 10mb file
  (find-file-noselect "c:/users/bburns/downloads/LibreOffice_4.3.6_Win_x86.msi" t) ; 220mb file

;; test .org file fontification
(message "%f" (benchmark-elapse 
  (find-file-noselect "test10m.org" t) ; 10mb file

My init file is fairly large so takes a while to load - it exercises loading the exe and running a lot of elisp code, loading a file tests the underlying C code and buffer handling, and loading the .org file exercises fontification.

So for these tests, it looks like the 64-bit build is slower, unless the 32-bit build had some different optimization settings - the README for the GNU Emacs distribution doesn't have any information on the build, so presumably it was just a plain make, which is what the 64-bit build used, if it used the procedure on the wiki.

The build process for 64-bit is easier, at least as far as setting up the environment, but I think you can also make a 32-bit build using MSYS2, so I'll add some tests for that when I get a chance.

See here also for a discussion on some performance differences between 32 and 64 bit applications.

And just for completeness, the .org file was just repeated blocks of

* headline 1

This is some text.

** subheading 1

This is some more text

** subheading 2

This is a table 

| one | two | three |
|   1 |   2 |     3 |
|     |     |       |
  • great! So the answer is "no, it's not faster"
    – fommil
    Jan 10, 2016 at 21:14
  • Yeah, apparently not, at least for these tests - I guess 64-bit would mostly help for number crunching or multimedia applications. Jan 10, 2016 at 22:12
  • 1
    You should test a large file requiring font-lock such as really large org-files or really large C-files or such. Automatically generated C-code can easily grow significantly over 100 MB. The binary files in your examples are opened with fundamental-mode and with raw character encoding. Emacs has not very much work with such files.
    – Tobias
    Jan 10, 2016 at 22:39
  • I'd like to see what @Tobias suggests
    – fommil
    Jan 10, 2016 at 23:15
  • Further aspects are: 1) Files with very long lines. Even if those lines are truncated emacs tries to font-lock them. 2) Repeated pressing of page-down and page-up in very large files with font-lock. If you keep the page-down button pressed emacs needs to font-lock the stuff you would potentially see while you press the down/up button. This can cause temporary hanging during scroll operations.
    – Tobias
    Jan 10, 2016 at 23:27

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.