Re: Regarding performance issues with the Emacs 25.1 Windows-build

["Jostein Kjønigsen" <jostein@secure.kjonigsen.net>]

[-- Attachment #1: Type: text/plain, Size: 4170 bytes --]

Hey everyone.

Sorry about the slow response. I've been ill, and haven't had time to
test this in a production environment until now.

I've got good news and I got bad news. I'll try to  be as short and
concise as possible.


Test setup
=========

In my testing, I've taken the provided Emacs 25-build, downloaded the
corresponding GNU libraries prebuilt by ezwinports, and combined this
output in a common Emacs folder from where I've run my tests.

My tool for automating this process is available online[1].


Performance results
==================

My quickest attempt to do semi-scientific testing is checking with
Windows Performance Recorder, how long a sustained 100% CPU usage period
is during startup on my current Emacs-configuration[2].

The results are below:

 * Emacs 25.1 (Phil's build): 7 seconds
 * Emacs 25.1 (GNU's release-build): 12 seconds
 * Emacs 24.5 (GNU's release-build): 7 seconds

Phil's build thus has the same performance characteristics as Emacs 24.5
for Windows.

And I'd love to say that this was the end of the story... but... I like
to do real world testing too :)


Functional Regressions
====================

I've found functional regressions in Phil's build, especially in what
seems to be handling of incoming XML data from inferior processes. This
error is not found in the official GNU build currently published for
Emacs 25.1, nor in Emacs 24.5.

My use-case is fairly simple:

 * Ensure eslint is installed globally in your environment (Install
   NodeJS, and then do "npm install -g eslint")
 * Open a JS-file which should trigger eslint warnings.
 * Enable flycheck-mode (which in turn will invoke eslint).

In this case, opening a file with eslint warnings yields no in-buffer
flycheck errors, but instead a error-message in the minibuffer saying
something to the extent of this:

> Suspicious state from syntax checker javascript-eslint: Flycheck
> checker javascript-eslint returned non-zero exit code 1, but its
> output contained no errors: <?xml version="1.0" encoding="utf-
> 8"?><checkstyle version="4.3"><file name="--redacted--"><error
> line="13" column="7" severity="error" message="&apos;tsify&apos; is
> assigned a value but never used. (no-unused-vars)" source="eslint.rules.no-unused-
> vars" /><error line="130" column="37" severity="error"
> message="Strings must use doublequote. (quotes)"
> source="eslint.rules.quotes" /><error line="130" column="44"
> severity="error" message="Strings must use doublequote. (quotes)"
> source="eslint.rules.quotes" /></file></checkstyle>

Is Emacs not able to load libxml? Are DLLs linked correctly? Is there
any way I can help and do diagnostics on my end?

This seems like a symptom of a pretty critical issue which will needs to
be resolved before any new release-build can be published. Let me know
how I can help.


References:

[1] https://github.com/josteink/machine-build/blob/master/tools/emacs-win32-bootstrap.cmd
[2] https://github.com/josteink/machine-build/blob/master/dotfiles/emacs/dot-emacs.el

--
Jostein Kjønigsen
🥓
jostein@kjonigsen.net / jostein@secure.kjonigsen.net / jostein@gmail.com
https://jostein.kjonigsen.net


On Mon, Nov 14, 2016, at 07:12 PM, Eli Zaretskii wrote:
>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: emacs-devel@gnu.org,  jostein@kjonigsen.net,
>> npostavs@users.sourceforge.net
>> Date: Mon, 14 Nov 2016 16:55:27 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> It's okay.  In general, if you don't strip the binaries, it would be
>>> better to also include -g3 in CFLAGS (so that there's debug info
>>> there, and reports about crashes can be accompanied by meaningful
>>> information), but for a release it is less important than for a
>>> pretest, so I see no need for yet another build.
>>
>> Confused? You mean to have four builds in total?
>
> No, of course not.  Just 2: one for x86, the other x86_64.
>
>> Or you want me to configure with:
>>
>> CFLAGS="-O2 -static -g3"
>
> That's the best if you don't strip the binaries, yes.
>
> Thanks, and sorry for the confusion I caused.

[-- Attachment #2: Type: text/html, Size: 6369 bytes --]