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

feklee
  • 1,029
  • 5
  • 17
  • 3
    Try [inhibit-message](http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS.25#n1395) – npostavs Jan 28 '19 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 '19 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 '19 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 '19 at 15:10
  • OK, good. Then I think the question is clear. I mentioned this only because the only feedback, so far, was a comment suggesting something that might speed it up. – Drew Jan 28 '19 at 15:24
  • Thing is, I now wonder if Emacs is generally slow on X. It would be totally awesome if someone else could do similar comparisons, doesn't even need to involve Windows. – feklee Jan 28 '19 at 16:19
  • @Drew I didn't specifically suggest that to speed it up, but in response to "[...]disable the minibuffer, which I don't think is possible." Anyway, based on the results we can rule out messages in the minibuffer as the source of the slowdown. Might be worth trying to disable the `*Compile Log*` popup, maybe with advice? – npostavs Jan 28 '19 at 17:30
  • 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 '19 at 18:20
  • 1
    For the Linux in virtual machines... They're compiled with GTK. What if you compile with the Lucid toolkit instead? (just as a test) – Cedric Martin Feb 23 '19 at 21:59
  • @CedricMartin Running Lucid now. Doesn't *feel* feel different performance-wise to the GTK+ version. Need to do proper tests, though, such as installing a big package, for example `org` or `auctex`. – feklee Mar 05 '19 at 16:56

0 Answers0