From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?Q?Jostein=20Kj=C3=B8nigsen?= Newsgroups: gmane.emacs.devel Subject: Re: Regarding performance issues with the Emacs 25.1 Windows-build Date: Tue, 15 Nov 2016 14:30:47 +0100 Message-ID: <1479216647.3987323.788371497.0DE981F1@webmail.messagingengine.com> References: <1478680445.2214391.782069929.51F43E52@webmail.messagingengine.com> <83shr0fwsu.fsf@gnu.org> <83oa1ofu6u.fsf@gnu.org> <87a8d7f0uo.fsf@russet.org.uk> <83k2cae9gt.fsf@gnu.org> <87h97deo1h.fsf@russet.org.uk> <87vavqxdgh.fsf@russet.org.uk> <831syehw56.fsf@gnu.org> <87wpg6vw5c.fsf@russet.org.uk> <83y40mgccr.fsf@gnu.org> <1479206967.3955707.788215361.663DEC5B@webmail.messagingengine.com> <1479210173.3966163.788279825.21F1DD58@webmail.messagingengine.com> <80b07e1bcdffb365d8d1105614e3f7ec.squirrel@cloud103.planethippo.com> Reply-To: jostein@kjonigsen.net NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_----------=_147921664839873230" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1479216717 2319 195.159.176.226 (15 Nov 2016 13:31:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 15 Nov 2016 13:31:57 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, npostavs@users.sourceforge.net To: Phillip Lord , jostein@kjonigsen.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 15 14:31:52 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6dpp-0006yg-SS for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2016 14:31:38 +0100 Original-Received: from localhost ([::1]:46492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6dpt-0007fb-3E for ged-emacs-devel@m.gmane.org; Tue, 15 Nov 2016 08:31:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6dpA-0007eC-Cv for emacs-devel@gnu.org; Tue, 15 Nov 2016 08:30:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6dp7-0006iu-TV for emacs-devel@gnu.org; Tue, 15 Nov 2016 08:30:56 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:33021) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6dp3-0006gw-0B; Tue, 15 Nov 2016 08:30:49 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6537120EB1; Tue, 15 Nov 2016 08:30:48 -0500 (EST) Original-Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Tue, 15 Nov 2016 08:30:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:content-transfer-encoding :content-type:date:from:in-reply-to:message-id:mime-version :references:reply-to:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=mesmtp; bh=Ugh1R+rfcfAKr5VHwd5Qk8zsSsk=; b=NV4GpC v4NmINIt9uD3yMKncuW0yvFKwTnTKO+PTOef7NEUUOhXa6Jd3Lp0J/w+eAJ0iAMJ mZ7+ex6L0V+pJGriTMQv7fa/ZxVdxjcsoTKPtSCnKFyAlCA7P5NWZKKHpDA0Wizq 9+6myMx7okH9Og96n3tg8NNFt7pJyJ+dI4uIQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :reply-to:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= smtpout; bh=Ugh1R+rfcfAKr5VHwd5Qk8zsSsk=; b=IA/Z/TYl4gsh6KnAcBiZ Pbh3T6QncMC5yLkBKXAiA/E4HHXeUYANqEEuRjJTTO6qdRQRJ1UyDVq476HSUqz3 AnHoR2aYkoEoGoa8rk4pwKuWEgCEGPAbZKlJhs5fx6cnY4KAmaoQ7TPFDi9Xu7O/ v9/gbdfCWXX9dCxzSwnhBzQ= X-ME-Sender: Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2BCFF5A67B; Tue, 15 Nov 2016 08:30:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface - ajax-461bce03 In-Reply-To: <80b07e1bcdffb365d8d1105614e3f7ec.squirrel@cloud103.planethippo.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.28 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209418 Archived-At: This is a multi-part message in MIME format. --_----------=_147921664839873230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Yes. This is with all the dependencies added, systematically and scripted, as outlined in the test-setup procedure. Both builds are tested using the same test-setup. libxml2-2.dll is found in the bin folder for all tested configurations. For whatever reason your latest build seems unable to load these dependencies. If libxml fails to load, my assumption was that other dependencies like image-support, GnTLS support, etc would also fail to load. So I did a test: I ran the following in a scratch buffer: (gnutls-available-p). On your build I'm getting "nil". For the other GNU builds, I'm getting "t". Again: I'm using the exact same test-setup across all Emacs versions here. Your 25.1.2-build clearly has fundamental issues with loading external libraries, although I'm not particularly qualified to point out what is failing here. But as far as I can tell, you now have at least 2 simple test-cases (eww, gnutls-available-p) with minimal dependencies and 1 scripted procedure[1] to setup the same test-environment I have. Hopefully that should be enough to help you dig deeper into what's going wrong here. [1] https://github.com/josteink/machine-build/blob/master/tools/emacs-win32= -bootstrap.cmd -- Jostein Kj=C3=B8nigsen =F0=9F=A5=93 jostein@kjonigsen.net / jostein@secure.kjonigsen.net / jostein@gmail.com https://jostein.kjonigsen.net On Tue, Nov 15, 2016, at 02:17 PM, Phillip Lord wrote: > > Is this with or without the extra dependencies added? > > Phil > > > On Tue, November 15, 2016 11:42 am, Jostein Kj=C3=B8nigsen wrote: >> Functional regressions - more info >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> >> >> 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=C3=B8nigsen >> =F0=9F=A5=93 >> 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=C3=B8nigsen 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 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> 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 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> 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 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> 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: >>> 8"?>>>> line=3D"13" column=3D"7" severity=3D"error" message=3D"'tsify' is >>>> assigned a value but never used. (no-unused-vars)" >>>> source=3D"eslint.rules.no-unused- vars" />>>> column=3D"37" >>>> severity=3D"error" message=3D"Strings must use doublequote. (quotes)" >>>> source=3D"eslint.rules.quotes" />>>> severity=3D"error" message=3D"Strings must use doublequote. (quotes)" >>>> source=3D"eslint.rules.quotes" /> >>> >>> 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=C3=B8nigsen >>> =F0=9F=A5=93 >>> 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 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=3D"-O2 -static -g3" >>>>> >>>> >>>> That's the best if you don't strip the binaries, yes. >>>> >>>> >>>> Thanks, and sorry for the confusion I caused. >>>> >>> >> > > --_----------=_147921664839873230 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Yes. This is with all the dependencies added, systematically and= scripted, as outlined in the test-setup procedure. Both builds are tested = using the same test-setup. libxml2-2.dll is found in the bin folder for all= tested configurations.

For whatever reason your latest build seems unable to load these depen= dencies.

If libxml fails to load, my assumption was that other dependencies lik= e image-support, GnTLS support, etc would also fail to load. So I did a tes= t: I ran the following in a scratch buffer:

(gnutls-available-p).

On your build I'm getting "nil". For the other GNU builds, I'm getting= "t". Again: I'm using the exact same test-setup across all Emacs versions = here.

Your 25.1.2-build clearly has fundamental issues with loading external= libraries, although I'm not particularly qualified to point out what is fa= iling here.

But as far as I can tell, you now have at least 2 simple test-cases (e= ww, gnutls-available-p) with minimal dependencies and 1 scripted procedure[= 1] to setup the same test-environment I have.

Hopefully that should be enough to help you dig deeper into what's goi= ng wrong here.


--
Jostein Kj=C3=B8nigsen
=F0=9F=A5=93
jostein@k= jonigsen.net / jostein@= secure.kjonigsen.net / jostein@gma= il.com
https://jostein.kjonigsen.net


On Tue, Nov 15, 2016, at 02:17 PM, Phillip Lord wrote:

Is this with or without the extra dependencies added?

Phil


On Tue, November 15, 2016 11:42 am, Jostein Kj=C3=B8nigsen wrote:
<= /div>
Functional regressions - more info
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D


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
<= /div>
publishing a new test-build, right?

--
Jostein Kj=C3=B8nigsen
=F0=9F=A5=93
jostein@kjonigsen.net / <= a href=3D"mailto:jostein@secure.kjonigsen.net">jostein@secure.kjonigsen.net= / jostein@gmail.com



On Tue, Nov 15, 2016, at 11:49 AM, Jostein Kj=C3=B8nigsen wrote:

Hey everyone.


Sorry about the slow response. I've been ill, and haven't had time to<= br>
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 a= nd
concise as possible.


Test setup
=3D=3D=3D=3D=3D=3D=3D=3D=3D


In my testing, I've taken the provided Emacs 25-build, downloaded the<= br>
corresponding GNU libraries prebuilt by ezwinports, and combined this<= br>
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


My quickest attempt to do semi-scientific testing is checking with
=
Windows Performance Recorder, how long a sustained 100% CPU usage
<= /div>
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


I've found functional regressions in Phil's build, especially in what<= br>
seems to be handling of incoming XML data from inferior processes. Thi= s
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<= br>
flycheck errors, but instead a error-message in the minibuffer saying<= br>
something to the extent of this:

Suspicious state from syntax checker javascript-eslint: Fl= ycheck
checker javascript-eslint returned non-zero exit code 1, but its outpu= t
contained no errors: <?xml version=3D"1.0" encoding=3D"utf-
8"?><checkstyle version=3D"4.3"><file name=3D"--redacted--= "><error
line=3D"13" column=3D"7" severity=3D"error" message=3D"'tsify' is
<= /div>
assigned a value but never used. (no-unused-vars)"
source=3D"eslint.rules.no-unused- vars" /><error line=3D"130" co= lumn=3D"37"
severity=3D"error" message=3D"Strings must use doublequote. (quotes)"<= br>
source=3D"eslint.rules.quotes" /><error line=3D"130" column=3D"4= 4"
severity=3D"error" message=3D"Strings must use doublequote. (quotes)"<= br>
source=3D"eslint.rules.quotes" /></file></checkstyle>

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

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


References:


[1]
-bootstrap.cmd
[2]
t-emacs.el

--
Jostein Kj=C3=B8nigsen
=F0=9F=A5=93
jostein@kjonigsen.net / <= a href=3D"mailto:jostein@secure.kjonigsen.net">jostein@secure.kjonigsen.net= / jostein@gmail.com



On Mon, Nov 14, 2016, at 07:12 PM, Eli Zaretskii wrote:

From: phillip.lord@russet.org.uk (Phillip Lord)
npostavs@users.sourc= eforge.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 binari= es, 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
<= /div>
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=3D"-O2 -static -g3"


That's the best if you don't strip the binaries, yes.


Thanks, and sorry for the confusion I caused.






--_----------=_147921664839873230--