4

Setup

  • Windows 10 host with X server (VcXsrv)

  • Linux guest (Arch) in virtual machine (VMware)

Benchmark

(defmacro measure-time (&rest body)
  "Measure the time it takes to evaluate BODY."
  `(let ((time (current-time)))
     ,@body
     (message "%.06f" (float-time (time-since time)))))
(measure-time (byte-recompile-directory package-user-dir nil 'force))

Results

Total of 285 files compiled, 22 skipped in 16 directories

  1. Native Emacs on Windows: 11.5 sec

  2. emacs -nw in Linux virtual machine: 5.1 sec

  3. Emacs in Linux virtual machine, displayed in X on the same machine (startx): 31.9 sec

  4. Emacs in Linux virtual machine, displayed in X server on Windows:

    • 33.6 sec (X11 forwarding via PuTTY SSH, uncompressed)

    • 32.5 sec (direct access from virtual machine to X server port 6000 on host via VMware host only networking / Windows firewall disabled)

Question

Is it normal that Emacs on X is that much slower than emacs -nw? In any case, what may be the cause for the slowness?

At first I only tested 4, and I was thinking that there is some network overhead between Linux and Windows which is causing the problem. Now I see that even with X on the same virtual machine (result number 3) slowness is an issue.

Only explanation for me is that the status messages in the mini buffer cause too much network traffic. To test that it would be interesting to completely disable the minibuffer, which I don't think is possible.

More benchmarks

For completeness, as I just have all that installed:

  • emacs -nw in WSL (Ubuntu):

    • Defender on: 10.3 sec

    • Defender off: 6.1 sec

  • Emacs in WSL, displayed in X server on Windows:

    • Defender on: 44.4 sec

    • Defender off: 36.3 sec

  • emacs -nw in Mingw-w64: 9.7 sec

  • Emacs in Mingw-w64, displayed in X server on Windows: 17.4 sec

Version details

  • Native Emacs on Windows: GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30

  • Emacs in Linux virtual machine: GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-07-05

  • Emacs in WSL: GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-05-29

  • Emacs in Mingw-w64: GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30

  • 3
    Try inhibit-message – npostavs Jan 28 at 13:57
  • @npostavs Basically same preformace with inhibit-message. Then a *Compile Log* buffer is shown, although it quickly gets filled with output, and then the display doesn't need to be updated anymore. – feklee Jan 28 at 14:55
  • Is your question really why it is slower? Or are you asking for ways to speed up byte-compilation (how) in that context? If the latter then please change the title and make clear what the question is. – Drew Jan 28 at 15:06
  • @Drew Yes, I would like to know why it is slower. Byte compilation is only an example. I assume there are other situations where the slowness can be experienced as well. – feklee Jan 28 at 15:10
  • 1
    You could try something like: (defmacro without-messages (&rest body) "Run BODY without messages." (declare (debug (body))) `(cl-letf (((symbol-function 'message) (symbol-function 'ignore)) ((symbol-function 'byte-compile-log) (symbol-function 'ignore)) ((symbol-function 'byte-compile-log-warning) (symbol-function 'ignore))) ,@body)) It also suppresses output to the message buffer and to the compile-log buffers. – Tobias Jan 28 at 18:20

Your Answer

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.

Browse other questions tagged or ask your own question.