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

["Phillip Lord" <phillip.lord@russet.org.uk>]

Is this with or without the extra dependencies added?

Phil


On Tue, November 15, 2016 11:42 am, Jostein Kjønigsen wrote:
> Functional regressions - more info
> ================================
>
>
> Regarding the functional regressions and the test-results found so far,
> the most obvious test-case I could find for failed XML-parsing was eww.
>
> So I tried to load www.google.com using eww, and as I suspected, it
> failed. It even specifically failed with saying the following:
>
>> Contacting host: www.google.com:80
>> libxml2 library not found
>
> Phil: This should be fairly easy for you to verify locally before
> publishing a new test-build, right?
>
> --
> Jostein Kjønigsen
> 🥓
> jostein@kjonigsen.net / jostein@secure.kjonigsen.net / jostein@gmail.com
> https://jostein.kjonigsen.net
>
>
>
> On Tue, Nov 15, 2016, at 11:49 AM, Jostein Kjønigsen wrote:
>
>> 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/do
>> t-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.
>>>
>>
>