4

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?

fommil
  • 1,750
  • 11
  • 24
  • See also -- **How to build Emacs master branch (aka trunk) on MS-Windows** -- http://emacs.stackexchange.com/questions/16971/how-to-build-emacs-master-branch-aka-trunk-on-ms-windows -- **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 09 '16 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 09 '16 at 17:05
  • Note, that there are 64-bit binary builds: http://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 09 '16 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 09 '16 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. – Brian Burns Jan 10 '16 at 16:57
  • @bburns.km yes, it would be very interesting to get hard numbers on these things. Do you have them? – fommil Jan 10 '16 at 18:06
  • Just agreeing that it would be interesting - I was planning to do a build of Emacs 24 and compare it with the GNU binaries tonight if no one had answered by then, but I've got some time to try it now. – Brian Burns Jan 10 '16 at 18:31
  • excellent @bburns.km that's exactly the kind of thing I was looking for! Looking forward to the numbers. I'm not sure what would be sensible benchmarks to run, but hopefully you'll find something. – fommil Jan 10 '16 at 18:51

1 Answers1

5

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 |
|     |     |       |
Community
  • 1
Brian Burns
  • 1,577
  • 14
  • 15
  • great! So the answer is "no, it's not faster" – fommil Jan 10 '16 at 21:14
  • Yeah, apparently not, at least for these tests - I guess 64-bit would mostly help for number crunching or multimedia applications. – Brian Burns Jan 10 '16 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 '16 at 22:39
  • I'd like to see what @Tobias suggests – fommil Jan 10 '16 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 '16 at 23:27
  • @Tobias (cc @fommil) Good idea - fontification turned out to be about 20% slower with 64-bit - when I get a chance I'll test with a 32-bit MSYS2 build also (I /think/ that's possible). – Brian Burns Jan 11 '16 at 00:30
  • FYI I tried out the 64 bit version on my VM and it was quite a bit snappier and more responsive for me! So I think I'll push to get it installed at work. – fommil Jan 12 '16 at 21:23
  • @fommil Interesting, maybe something to do with using a VM? – Brian Burns Jan 12 '16 at 23:05
  • @bburns.km when I get it installed at work, I'll run your benchmark and post as a second answer. Please continue the good work of finding alternative automated performance tests! – fommil Jan 12 '16 at 23:08
  • @fommil Okay that would be great. And yeah it would be nice to have a set of automated benchmarks to run - I'll probably cut the .org file down to 1 or 2mb so the test doesn't take so long to run, and see if the % difference is comparable. Also working on a comparison with all 3 build methods (MSYS 32bit, MSYS2 32bit, MSYS2 64bit), and maybe some of the Emacs profiling tools would help with automating this. It's good to find the fastest version possible - I didn't think there would be such a difference in the versions. – Brian Burns Jan 12 '16 at 23:38
  • btw, you could potentially use appveyor to automate this from a github repo. Check out how we use it in ensime-emacs for integration tests. It's a gratis service. – fommil Jan 13 '16 at 08:34