Regarding performance issues with the Emacs 25.1 Windows-build

Regarding performance issues with the Emacs 25.1 Windows-build

[Jostein Kjønigsen]

Hey everyone.

I'm a platform-hopping Emacs-user using Linux at home and Windows at
work.

At home I run Emacs built from source, but getting a Windows-build of
Emacs going seems a bit more involved than "apt source emacs", so I run
the pre-compiled binaries provided by GNU.

Thus I was very excited the final release of Emacs 25.1. Finally I could
use these new features on my WIndows-workstation at work as well!

But now I'm going back to 24.5. Why? It seems Emacs 25.1 for Windows has
major performance issues. Compared to Emacs 24.5 it's just on overall
slower for just about anything.

At first I thought it was just the 64-bit build which was affected
(thanks for 64-bit btw!). But after using the 32-bit build for a while,
I can just *tell* that everything is moving slower than it used to.

Now to be truthful, I haven't been fully methodical and scientific about
this. I've noticed, but I haven't systematically measured anything.

The good news is that someone else has done just this:
https://www.reddit.com/r/emacs/comments/598iot/on_windows_emacs_251_is_noticeably_slower_than/

The numbers here show Emacs 25.1 on Windows to be almost twice as slow
as 24.5!

Now on Linux I'm having none of these issues, so my suspicion is
targeted towards the build itself, more than the code-base.

How was the Windows-version built? Was it built by the same people,
using the same setup and the same toolchain? Or was something done
differently this time?

Windows still has significant marketshare so I don't think we're doing
Emacs or GNU any good by having it's first-class editor appear sluggish.

Anyone have idea how we can go about this fixing this?

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

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

[Eli Zaretskii]

> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
> Date: Wed, 09 Nov 2016 09:34:05 +0100
> 
> https://www.reddit.com/r/emacs/comments/598iot/on_windows_emacs_251_is_noticeably_slower_than/
> 
> The numbers here show Emacs 25.1 on Windows to be almost twice as slow
> as 24.5!

My measurement show only a very mild slowdown, about 20% to 30%.
Nowhere near twice slower.  The last timing in the benchmark posted to
reddit is actually twice _faster_ with Emacs 25.1.

FWIW, I don't feel any slowdown in day-to-day usage of Emacs, which is
consistent with the above measurements.

The only significant change in Emacs 25.1 on Windows is how we
allocate memory, AFAIR.  However, the posted benchmark doesn't
allocate any significant memory, AFAICT.

> How was the Windows-version built? Was it built by the same people,
> using the same setup and the same toolchain? Or was something done
> differently this time?

The answer is probably that it was not built the same, but I very much
doubt that the differences could explain a twofold performance hit.

FWIW, my binaries were built by myself using the same compilation
options (-O2 optimization), but I upgraded my compiler from GCC 4.8.1
to 5.3.0 between the two versions of Emacs.  Again, I very much doubt
that this could explain any significant performance differences.

> Anyone have idea how we can go about this fixing this?

The first step is to identify which part(s) are now slower.

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

[Noam Postavsky]

On Wed, Nov 9, 2016 at 11:22 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>> How was the Windows-version built? Was it built by the same people,
>> using the same setup and the same toolchain? Or was something done
>> differently this time?
>
> The answer is probably that it was not built the same, but I very much
> doubt that the differences could explain a twofold performance hit.
>
> FWIW, my binaries were built by myself using the same compilation
> options (-O2 optimization), but I upgraded my compiler from GCC 4.8.1
> to 5.3.0 between the two versions of Emacs.  Again, I very much doubt
> that this could explain any significant performance differences.

I think the problem is that the 25.1 build is not optimized: I did M-x
report-emacs-bug in each, notice that 25.1 has a setting for CFLAGS
which doesn't include -O2, while 24.5 doesn't have one (and hence uses
the default, which I believe does include -O2).

In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17 built on LAPHROAIG
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'

In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 9 Nov 2016 11:55:04 -0500
> Cc: jostein@kjonigsen.net, Emacs developers <emacs-devel@gnu.org>
> 
> I think the problem is that the 25.1 build is not optimized: I did M-x
> report-emacs-bug in each, notice that 25.1 has a setting for CFLAGS
> which doesn't include -O2, while 24.5 doesn't have one (and hence uses
> the default, which I believe does include -O2).
> 
> In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
>  of 2016-09-17 built on LAPHROAIG
> Configured using:
>  'configure --without-dbus --without-compress-install CFLAGS=-static'
> 
> In GNU Emacs 24.5.1 (i686-pc-mingw32)
>  of 2015-04-11 on LEG570
> Windowing system distributor `Microsoft Corp.', version 6.3.9600
> Configured using:
>  `configure --prefix=/c/usr --host=i686-pc-mingw32'

That could indeed be the culprit: omitting -O2 makes Emacs 2 to 3
times slower, IME.

Phillip, could you please double-check the value of CFLAGS in the
Makefiles in your build tree?  Does it include any optimization
options?

Thanks.

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

[Eli Zaretskii]

> Date: Wed, 09 Nov 2016 18:22:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> My measurement show only a very mild slowdown, about 20% to 30%.

And I think this slowdown is because I built 25.1 --with-wide-int
(it's a 32-bit build), which is expected to be slower by that amount.

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

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Wed, 9 Nov 2016 11:55:04 -0500
>> Cc: jostein@kjonigsen.net, Emacs developers <emacs-devel@gnu.org>
>> 
>> I think the problem is that the 25.1 build is not optimized: I did M-x
>> report-emacs-bug in each, notice that 25.1 has a setting for CFLAGS
>> which doesn't include -O2, while 24.5 doesn't have one (and hence uses
>> the default, which I believe does include -O2).
>> 
>> In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
>>  of 2016-09-17 built on LAPHROAIG
>> Configured using:
>>  'configure --without-dbus --without-compress-install CFLAGS=-static'
>> 
>> In GNU Emacs 24.5.1 (i686-pc-mingw32)
>>  of 2015-04-11 on LEG570
>> Windowing system distributor `Microsoft Corp.', version 6.3.9600
>> Configured using:
>>  `configure --prefix=/c/usr --host=i686-pc-mingw32'
>
> That could indeed be the culprit: omitting -O2 makes Emacs 2 to 3
> times slower, IME.
>
> Phillip, could you please double-check the value of CFLAGS in the
> Makefiles in your build tree?  Does it include any optimization
> options?

I don't have the make files to hand, but I do have the commands that I
used, and yes, I did set CFLAGS=-static. IIRC, we had a long discussion
about this, and it was to avoid a dependency on libwinpthread. It didn't
occur to me that setting CFLAGS would effect other defaults.

I'll try and build with "-O2" added and check tonight.

Phil

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

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:
>> In GNU Emacs 24.5.1 (i686-pc-mingw32)
>>  of 2015-04-11 on LEG570
>> Windowing system distributor `Microsoft Corp.', version 6.3.9600
>> Configured using:
>>  `configure --prefix=/c/usr --host=i686-pc-mingw32'
>
> That could indeed be the culprit: omitting -O2 makes Emacs 2 to 3
> times slower, IME.
>
> Phillip, could you please double-check the value of CFLAGS in the
> Makefiles in your build tree?  Does it include any optimization
> options?


I've rebuilt using -O2 explicitly in CFLAGS and put it here:

http://www.russet.org.uk/scratch/

Using the benchmarks on the reddit link, it does make Emacs
significantly faster.

@Jostein Kjønigsen could you give these a go and let me know of your
experiences.

@Eli assuming that these binaries address the issue what do I do with
the version number in uploading them to ftp.gnu.org. I don't want to
over-write the existing ones, nor use the same version number.

Apologies all for these difficulties.

Phil

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

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>,  jostein@kjonigsen.net,  emacs-devel@gnu.org
> Date: Thu, 10 Nov 2016 22:04:31 +0000
> 
> @Eli assuming that these binaries address the issue what do I do with
> the version number in uploading them to ftp.gnu.org. I don't want to
> over-write the existing ones, nor use the same version number.

I'd remove the old ones and upload the new ones using 25.1-2 as the
version number in the file names.

Thanks.

P.S.  What compiler options did you use, exactly?  Also, are the
binaries in the archives stripped or unstripped?

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

[Jostein Kjønigsen]

So far this all sounds great. Good job everyone! :)

That said: I'm a Windows-user at work and Linux-user at home and today
I just wasn't in at the office.

I could try it out in a virtual machine on my laptop at home right
now, but I'd much rather try it on my regular work-station, with my
regular config and where I know what to expect performance and
responsiveness-wise.

That means I won't be able to test this until monday. Hopefully that
won't be a problem? I mean... So far 25.1 has been out for almost 2
months, so if 25.1.2 gets delayed a few days, probably won't hurt that
much?

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


On Thu, Nov 10, 2016, at 11:04 PM, Phillip Lord wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>>> In GNU Emacs 24.5.1 (i686-pc-mingw32)
>>> of 2015-04-11 on LEG570
>>> Windowing system distributor `Microsoft Corp.', version 6.3.9600
>>> Configured using:
>>> `configure --prefix=/c/usr --host=i686-pc-mingw32'
>> 
>> That could indeed be the culprit: omitting -O2 makes Emacs 2 to 3
>> times slower, IME.
>> 
>> Phillip, could you please double-check the value of CFLAGS in the
>> Makefiles in your build tree?  Does it include any optimization
>> options?
> 
> 
> I've rebuilt using -O2 explicitly in CFLAGS and put it here:
> 
> http://www.russet.org.uk/scratch/
> 
> Using the benchmarks on the reddit link, it does make Emacs
> significantly faster.
> 
> @Jostein Kjønigsen could you give these a go and let me know of your
> experiences.
> 
> @Eli assuming that these binaries address the issue what do I do with
> the version number in uploading them to ftp.gnu.org. I don't want to
> over-write the existing ones, nor use the same version number.
> 
> Apologies all for these difficulties.
> 
> Phil

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

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: Noam Postavsky <npostavs@users.sourceforge.net>,  jostein@kjonigsen.net,  emacs-devel@gnu.org
>> Date: Thu, 10 Nov 2016 22:04:31 +0000
>> 
>> @Eli assuming that these binaries address the issue what do I do with
>> the version number in uploading them to ftp.gnu.org. I don't want to
>> over-write the existing ones, nor use the same version number.
>
> I'd remove the old ones and upload the new ones using 25.1-2 as the
> version number in the file names.

Will do that.

>
> P.S.  What compiler options did you use, exactly?  Also, are the
> binaries in the archives stripped or unstripped?

These were the commands I used to produce the original binaries.


PKG_CONFIG_PATH=/mingw64/lib/pkgconfig ../../../git/emacs-25.1/configure --without-dbus --without-compress-install CFLAGS=-static
make -j 4 install prefix=/home/user/emacs-git/install/x86_64/emacs-25.1
cd /home/user/emacs-git/install/x86_64/emacs-25.1
cp /mingw64/bin/libXpm-noX4.dll bin
zip -r -9 emacs-25.1-x86_64-w64-mingw32.zip *


PKG_CONFIG_PATH=/mingw32/lib/pkgconfig ../../../git/emacs-25.1/configure --host=i686-w64-mingw32 --without-dbus --without-compress-install CFLAGS=-static 
make -j 4 install prefix=/home/user/emacs-git/install/i686/emacs-25.1
cd /home/user/emacs-git/install/i686/emacs-25.1
cp ~/emacs-git/libxpm/ezwinports/bin/libXpm-nox4.dll bin
zip -r -9 emacs-25.1-i686-w64-mingw32.zip *


And this are the command taht I used to produce the binary that I sent
yesterday.

PKG_CONFIG_PATH=/mingw64/lib/pkgconfig ../../../git/emacs-25.1/configure --without-dbus --without-compress-install CFLAGS="-O2 -static"
make -j 4 install prefix=/home/user/emacs-git/install/x86_64/emacs-25.1-2
cd /home/user/emacs-git/install/x86_64/emacs-25.1-2
cp /mingw64/bin/libXpm-noX4.dll bin
zip -r -9 emacs-25.1-2-x86_64-w64-mingw32.zip

Phil

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

[Phillip Lord]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: phillip.lord@russet.org.uk (Phillip Lord)
>>> Cc: Noam Postavsky <npostavs@users.sourceforge.net>,  jostein@kjonigsen.net,  emacs-devel@gnu.org
>>> Date: Thu, 10 Nov 2016 22:04:31 +0000
>>> 
>>> @Eli assuming that these binaries address the issue what do I do with
>>> the version number in uploading them to ftp.gnu.org. I don't want to
>>> over-write the existing ones, nor use the same version number.
>>
>> I'd remove the old ones and upload the new ones using 25.1-2 as the
>> version number in the file names.
>
> Will do that.
>
>>
>> P.S.  What compiler options did you use, exactly?  Also, are the
>> binaries in the archives stripped or unstripped?
>
> These were the commands I used to produce the original binaries.
>
>
> PKG_CONFIG_PATH=/mingw64/lib/pkgconfig ../../../git/emacs-25.1/configure --without-dbus --without-compress-install CFLAGS=-static
> make -j 4 install prefix=/home/user/emacs-git/install/x86_64/emacs-25.1
> cd /home/user/emacs-git/install/x86_64/emacs-25.1
> cp /mingw64/bin/libXpm-noX4.dll bin
> zip -r -9 emacs-25.1-x86_64-w64-mingw32.zip *
>
>
> PKG_CONFIG_PATH=/mingw32/lib/pkgconfig ../../../git/emacs-25.1/configure
> --host=i686-w64-mingw32 --without-dbus --without-compress-install
> CFLAGS=-static
> make -j 4 install prefix=/home/user/emacs-git/install/i686/emacs-25.1
> cd /home/user/emacs-git/install/i686/emacs-25.1
> cp ~/emacs-git/libxpm/ezwinports/bin/libXpm-nox4.dll bin
> zip -r -9 emacs-25.1-i686-w64-mingw32.zip *
>
>
> And this are the command taht I used to produce the binary that I sent
> yesterday.
>
> PKG_CONFIG_PATH=/mingw64/lib/pkgconfig ../../../git/emacs-25.1/configure --without-dbus --without-compress-install CFLAGS="-O2 -static"
> make -j 4 install prefix=/home/user/emacs-git/install/x86_64/emacs-25.1-2
> cd /home/user/emacs-git/install/x86_64/emacs-25.1-2
> cp /mingw64/bin/libXpm-noX4.dll bin
> zip -r -9 emacs-25.1-2-x86_64-w64-mingw32.zip


You happy with these Eli? If so, I can get the rebuild versions up as
soon as possible.

Phil

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

[Eli Zaretskii]

> 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 15:56:14 +0000
> 
> > PKG_CONFIG_PATH=/mingw64/lib/pkgconfig ../../../git/emacs-25.1/configure --without-dbus --without-compress-install CFLAGS="-O2 -static"
> > make -j 4 install prefix=/home/user/emacs-git/install/x86_64/emacs-25.1-2
> > cd /home/user/emacs-git/install/x86_64/emacs-25.1-2
> > cp /mingw64/bin/libXpm-noX4.dll bin
> > zip -r -9 emacs-25.1-2-x86_64-w64-mingw32.zip
> 
> You happy with these Eli? If so, I can get the rebuild versions up as
> soon as possible.

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.

Thanks.

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

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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 15:56:14 +0000
>> 
>> > PKG_CONFIG_PATH=/mingw64/lib/pkgconfig ../../../git/emacs-25.1/configure --without-dbus --without-compress-install CFLAGS="-O2 -static"
>> > make -j 4 install prefix=/home/user/emacs-git/install/x86_64/emacs-25.1-2
>> > cd /home/user/emacs-git/install/x86_64/emacs-25.1-2
>> > cp /mingw64/bin/libXpm-noX4.dll bin
>> > zip -r -9 emacs-25.1-2-x86_64-w64-mingw32.zip
>> 
>> You happy with these Eli? If so, I can get the rebuild versions up as
>> soon as possible.
>
> 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? Or you want me to
configure with:

CFLAGS="-O2 -static -g3"

I'm obviously doing the build anyway.

Phil

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

[Eli Zaretskii]

> 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.

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

[Jostein Kjønigsen]

[-- 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 --]

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

[Jostein Kjønigsen]

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

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/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: 7704 bytes --]

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

[Phillip Lord]

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.
>>>
>>
>

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

[Jostein Kjønigsen]

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

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ønigsen
🥓
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ø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="'tsify' 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.
>>>>
>>>
>>
>
>

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

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

[Eli Zaretskii]

> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, npostavs@users.sourceforge.net,
>  emacs-devel@gnu.org
> Date: Tue, 15 Nov 2016 14:30:47 +0100
> 
> 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.

I think the problem is that you downloaded a 64-bit build of Emacs,
but your dependencies are from the ezwinports site, which provides
only 32-bit DLLs, and those cannot be loaded by 64-bit programs.

You should either use the 64-bit dependencies from the GNU FTP site,
or wait for Phillip to upload a new 32-bit build to the GNU FTP site.

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

[Jostein Kjønigsen]

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

Thanks Eli.

That's absolutely correct, and a major blunder on my part. My bad. Sorry
about that!

I've rebuilt the test-setup for Phil's Emacs 25.1-build using the 64-bit
DLLs provided by GNU:
http://ftp.gnu.org/gnu/emacs/windows/emacs-25-x86_64-deps.zip

Using Windows Performance Recorder, the build still runs at the same
speed as Emacs 24.5 (7 seconds intense start up period) and seemingly
loads all external libraries fine (I've tested gnutls, libxml2 and image-
support indirectly through eww).

I guess that means that this build is fine as far as I can see. Sorry
about the noise.

If this build gets published on the GNU website, I would consider this
issue resolved as far as I am concerned.

Thanks for your efforts, everyone!

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


On Tue, Nov 15, 2016, at 04:17 PM, Eli Zaretskii wrote:
>> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>, npostavs@users.sourceforge.net,
>> emacs-devel@gnu.org
>> Date: Tue, 15 Nov 2016 14:30:47 +0100
>>
>> 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.
>
> I think the problem is that you downloaded a 64-bit build of Emacs,
> but your dependencies are from the ezwinports site, which provides
> only 32-bit DLLs, and those cannot be loaded by 64-bit programs.
>
> You should either use the 64-bit dependencies from the GNU FTP site,
> or wait for Phillip to upload a new 32-bit build to the GNU FTP site.

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

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

[Phillip Lord]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> That's absolutely correct, and a major blunder on my part. My bad. Sorry
> about that!
>
> I've rebuilt the test-setup for Phil's Emacs 25.1-build using the 64-bit
> DLLs provided by GNU:
> http://ftp.gnu.org/gnu/emacs/windows/emacs-25-x86_64-deps.zip
>
> Using Windows Performance Recorder, the build still runs at the same
> speed as Emacs 24.5 (7 seconds intense start up period) and seemingly
> loads all external libraries fine (I've tested gnutls, libxml2 and image-
> support indirectly through eww).
>
> I guess that means that this build is fine as far as I can see. Sorry
> about the noise.

It's not noise, it's testing, and I am happy to see it! Getting feedback
is essential for getting the job done correctly, and I'm grateful for it.

> If this build gets published on the GNU website, I would consider this
> issue resolved as far as I am concerned.

I've put the two new binaries on alpha

http://alpha.gnu.org/gnu/emacs/pretest/

Feedback welcome.

Phil

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

[Fernando Febles Armas]

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

> I've put the two new binaries on alpha
> http://alpha.gnu.org/gnu/emacs/pretest/
> Feedback welcome.
> Phil

The new zip files almost double in size the previous ones. I've downloaded
the i686 version, and there are two files with the same content weighting
77Mb each one: 'emacs.exe' and 'emacs-25.1.exe'.

I've tested the performance with an old 2004 Sony VAIO, and the performance
is much better than the version compiled without optimizations: now I can
scroll without problems :-)

Still a bit slower than the 24.5 version. Loading emacs with my init file
takes 13.2 seconds with 25.1-2, and 10.6 with the older 24.5.

By the way, are the optional dependencies (emacs-25-x86_64-deps.zip and
emacs-25-i686-deps.zip) compiled with the -O2 performance option enabled?

Thanks for your great work.

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

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

[Eli Zaretskii]

> From: Fernando Febles Armas <fernandofebles@gmail.com>
> Date: Mon, 21 Nov 2016 23:35:50 +0000
> 
> The new zip files almost double in size the previous ones. I've downloaded the i686 version, and there are two
> files with the same content weighting 77Mb each one: 'emacs.exe' and 'emacs-25.1.exe'.

You can make a hard link from one to the other to save disk space.
These two executables are so that when you install the next version of
Emacs, you can still access the previous one, if you want.  It's
standard Emacs practice on all platforms.

The size of the binaries is large because it includes debug info.  The
previous build included only a basic debug info, this one includes
much more.  This is important when there are bugs to report.

> Still a bit slower than the 24.5 version. Loading emacs with my init file takes 13.2 seconds with 25.1-2, and
> 10.6 with the older 24.5.

Not in my experience, the performance is the same.

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

[Jostein Kjønigsen]

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

Hey Phil.



I haven't seen any more feedback on this on the public mailing-list
since I last emailed, so I don't know if you've received adequate, or
any feedback at all at this point.


I therefore wanted to let you know that I've now used this build as
"my daily driver" since you published it, as a replacement for
(previously superior) Emacs 24.5, and I've had no major complaints or
incidents so far.


In my opinion, as the one who originally raised this issue, I'm happy to
consider this issue resolved.


And let me say: Thanks again for your work. It's really appreciated!



--

Jostein Kjønigsen

🥓

jostein@kjonigsen.net / jostein@gmail.com

https://jostein.kjonigsen.net







On Sun, Nov 20, 2016, at 10:31 AM, Phillip Lord wrote:

> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

>> That's absolutely correct, and a major blunder on my part. My
>> bad. Sorry
>> about that!

>> 

>> I've rebuilt the test-setup for Phil's Emacs 25.1-build using
>> the 64-bit
>> DLLs provided by GNU:

>> http://ftp.gnu.org/gnu/emacs/windows/emacs-25-x86_64-deps.zip

>> 

>> Using Windows Performance Recorder, the build still runs at the same
>> speed as Emacs 24.5 (7 seconds intense start up period) and seemingly
>> loads all external libraries fine (I've tested gnutls, libxml2
>> and image-
>> support indirectly through eww).

>> 

>> I guess that means that this build is fine as far as I can see. Sorry
>> about the noise.

> 

> It's not noise, it's testing, and I am happy to see it! Getting
> feedback
> is essential for getting the job done correctly, and I'm
> grateful for it.
> 

>> If this build gets published on the GNU website, I would
>> consider this
>> issue resolved as far as I am concerned.

> 

> I've put the two new binaries on alpha

> 

> http://alpha.gnu.org/gnu/emacs/pretest/

> 

> Feedback welcome.

> 

> Phil



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

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

[Phillip Lord]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> I haven't seen any more feedback on this on the public mailing-list
> since I last emailed, so I don't know if you've received adequate, or
> any feedback at all at this point.


Yes, you'd replied and one piece of feedback is plenty! Just a bit
work-bombed at the moment, hence the slow movement.


> I therefore wanted to let you know that I've now used this build as
> "my daily driver" since you published it, as a replacement for
> (previously superior) Emacs 24.5, and I've had no major complaints or
> incidents so far.
>
>
> In my opinion, as the one who originally raised this issue, I'm happy to
> consider this issue resolved.

Good and timely feedback. The new version on ftp.gnu.org

https://ftp.gnu.org/gnu/emacs/windows/

I'll wait a few days and then remove the unoptimized version.

> And let me say: Thanks again for your work. It's really appreciated!

No worries, am glad to have got the feedback.

I'll try and get the next pre-release out of the door as soon as I can!

Phil

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

[Fabrice Popineau]

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

There is a user on Reddit who pretends that theses latest binaries of Emacs
run slower on Windows than on Linux.
I didn't get a chance yet to give it a try.
The test is as follows :

- Install Helm from MELPA.
- Add this config to the init file, as suggested by Helm page

https://www.reddit.com/r/emacs/comments/5e3xpu/emojis_in_emacs_intentionally_disabled_for_osx/dabya5i/

If anybody has a chance to do the testing. I'm not sure about what helm
config  he is
talking about (the full one or the default one).
My guess is that something else than emacs is disturbing his load time
(antivirus ?).
But that could be nice to have something asserted about this.

Regards,

Fabrice


2016-11-29 22:47 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:

> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
> > I haven't seen any more feedback on this on the public mailing-list
> > since I last emailed, so I don't know if you've received adequate, or
> > any feedback at all at this point.
>
>
> Yes, you'd replied and one piece of feedback is plenty! Just a bit
> work-bombed at the moment, hence the slow movement.
>
>
> > I therefore wanted to let you know that I've now used this build as
> > "my daily driver" since you published it, as a replacement for
> > (previously superior) Emacs 24.5, and I've had no major complaints or
> > incidents so far.
> >
> >
> > In my opinion, as the one who originally raised this issue, I'm happy to
> > consider this issue resolved.
>
> Good and timely feedback. The new version on ftp.gnu.org
>
> https://ftp.gnu.org/gnu/emacs/windows/
>
> I'll wait a few days and then remove the unoptimized version.
>
> > And let me say: Thanks again for your work. It's really appreciated!
>
> No worries, am glad to have got the feedback.
>
> I'll try and get the next pre-release out of the door as soon as I can!
>
> Phil
>
>


-- 
Fabrice Popineau
-----------------------------
CentraleSupelec
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

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

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

[Jostein Kjønigsen]

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

While I think comparing performance between Linux to Windows is a
reasonable to a certain extent, I don't think it should be done blindly.


What I think is more interesting is the platform-specific performance
with regard to prior versions.

 * When I upgraded from Emacs 24.5 to Emacs 25.1 on Linux, I didn't
   notice a difference in performance characteristics.
 * When I upgraded from Emacs 24.5 to Emacs 25.1 on Windows, I
   immediately noticed massive slowdowns.


That was my frame of reference when initially starting this thread. Due
to Emacs (or at least certain Emacs-packages) being heavily reliant on
sub-processes to do the heavy lifting, and the platforms' very different
performance-characteristics w.r.t. threads vs processes, I wouldn't
expect Emacs on Windows to perform exactly the same as on Linux.


I just don't think directly comparing performance between two platforms
as such is realistic, or that immediately useful.


Just look at Git for Windows. It's *much *slower than on Linux, due to
heavy sub-process use. But the performance in between versions stays
pretty much the same. As a user, as long as Emacs for Windows does the
same, I don't see a problem.


If however the Emacs-developers considers this a problem, feel free to
investigate it further at your own discretion :)


--

Jostein Kjønigsen

🥓

jostein@kjonigsen.net / jostein@gmail.com

https://jostein.kjonigsen.net







On Wed, Nov 30, 2016, at 08:56 AM, Fabrice Popineau wrote:

> There is a user on Reddit who pretends that theses latest binaries of
> Emacs run slower on Windows than on Linux.
> I didn't get a chance yet to give it a try.

> The test is as follows :

> 

> - Install Helm from MELPA.

> - Add this config to the init file, as suggested by Helm page

> 

> https://www.reddit.com/r/emacs/comments/5e3xpu/emojis_in_emacs_intentionally_disabled_for_osx/dabya5i/
> If anybody has a chance to do the testing. I'm not sure about what
> helm config  he is
> talking about (the full one or the default one).

> My guess is that something else than emacs is disturbing his load time
> (antivirus ?).
> But that could be nice to have something asserted about this.

> 

> Regards,

> 

> Fabrice

> 

> 

> 2016-11-29 22:47 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:
>> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
>>  > I haven't seen any more feedback on this on the public mailing-
>>  > list since I last emailed, so I don't know if you've received
>>  > adequate, or any feedback at all at this point.
>>
>>
>> Yes, you'd replied and one piece of feedback is plenty! Just a bit
>>  work-bombed at the moment, hence the slow movement.

>>
>>
>>  > I therefore wanted to let you know that I've now used this build
>>  > as "my daily driver" since you published it, as a replacement for
>>  > (previously superior) Emacs 24.5, and I've had no major complaints
>>  > or incidents so far.
>>  >
>>  >
>>  > In my opinion, as the one who originally raised this issue, I'm
>>  > happy to consider this issue resolved.
>>
>> Good and timely feedback. The new version on ftp.gnu.org
>> 

>> https://ftp.gnu.org/gnu/emacs/windows/

>> 

>>  I'll wait a few days and then remove the unoptimized version.

>>
>>  > And let me say: Thanks again for your work. It's really
>>  > appreciated!
>>
>> No worries, am glad to have got the feedback.
>> 

>>  I'll try and get the next pre-release out of the door as soon as
>>  I can!
>> 

>>  Phil

>> 

> 

> 

> 

> -- 

> Fabrice Popineau

> -----------------------------

> CentraleSupelec

> Département Informatique

> 3, rue Joliot Curie

> 91192 Gif/Yvette Cedex

> Tel direct : +33 (0) 169851950

> Standard : +33 (0) 169851212

> ------------------------------

> 



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

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

[Fabrice Popineau]

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

2016-11-30 9:36 GMT+01:00 Jostein Kjønigsen <jostein@secure.kjonigsen.net>:

> While I think comparing performance between Linux to Windows is a
> reasonable to a certain extent, I don't think it should be done blindly.
>

The OP stated that there is a 3x slowdown in startup time.

Either he is using the unoptimized binaries, or he has a slow antivirus or
whatever I don't know.
I don't think that emacs per se is slower under Windows than under
GNU/Linux.
(and I already discussed that with Eli).

Fabrice

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

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

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@centralesupelec.fr>
> Date: Wed, 30 Nov 2016 08:56:09 +0100
> Cc: jostein@kjonigsen.net, Eli Zaretskii <eliz@gnu.org>,
> 	Noam Postavsky <npostavs@users.sourceforge.net>,
> 	Jostein Kjønigsen <jostein@secure.kjonigsen.net>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> There is a user on Reddit who pretends that theses latest binaries of Emacs run slower on Windows than on
> Linux.
> I didn't get a chance yet to give it a try.
> The test is as follows :
> 
> - Install Helm from MELPA.
> - Add this config to the init file, as suggested by Helm page
> 
> https://www.reddit.com/r/emacs/comments/5e3xpu/emojis_in_emacs_intentionally_disabled_for_osx/dabya5i/
> 
> 
> If anybody has a chance to do the testing. I'm not sure about what helm config he is
> talking about (the full one or the default one).

Helm fires up a lot of subprocesses, and subprocess handling in Emacs
on MS-Windows is complicated and involves synchronization between
threads.  Maybe that is at least one reason for slower startup.

Another reason could be intensive file I/O, which is more efficient on
GNU/Linux (not related to Emacs).

> My guess is that something else than emacs is disturbing his load time (antivirus ?).

Yes, antivirus could be yet another reason.

But I agree that without a reproducible recipe, this discussion is a
bit academic.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > While I think comparing performance between Linux to Windows is a
  > reasonable to a certain extent,

It makes no sense to compare Linux with Windows.  Windows is an
operating system; Linux is a kernel, one component of an operating
system.

If you are thinking of a system that is comparable to Windows, and has
Linux in it, that must be the GNU/Linux system.  GNU/Linux is the GNU
operating system (which I launched in 1984) plus the kernel Linux.

GNU Emacs, which I started in September 1984, was the first component
of the GNU system to be released to users.  This list is used for
further development of GNU.

To call the whole GNU/Linux system "Linux" is to attribute our work to
Torvalds.  It's unfair to us, and it reduces our ability to do more
for users' freedom.  Please don't do that.

Please give us equal mention, by saying "GNU/Linux" when you mean the
whole system.

See http://gnu.org/gnu/linux-and-gnu.html and
http://gnu.org/gnu/gnu-linux-faq.html, plus the history in
http://gnu.org/gnu/the-gnu-project.html.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

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

[Fabrice Popineau]

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

Probably not very important, but since I had a look at it, I post it.

The original poster recipe was about running Emacs with helm and its
default configuration, nothing else.
Here are some figures using emacs 25.1 :

emacs/w64, Windows 10, running from msys2 bash:
$ time emacs -Q -l /tmp/helm-cfg.el -f kill-emacs

real    0m1.258s
user    0m0.000s
sys     0m0.000s

emacs/ubuntu, running from WSL:

$time ../../build-emacs-ubuntu/src/emacs -display :0 -Q -l
/mnt/c/MSys64/tmp/helm-cfg.el -f kill-emacs

real    0m1.441s
user    0m0.625s
sys     0m0.734s

One can object that the Ubuntu provided by WSL is not the Real Thing (TM),
but that should be close enough.
So I don't see a real difference here.

Regards,

Fabrice


2016-11-30 15:48 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau@centralesupelec.fr>
> > Date: Wed, 30 Nov 2016 08:56:09 +0100
> > Cc: jostein@kjonigsen.net, Eli Zaretskii <eliz@gnu.org>,
> >       Noam Postavsky <npostavs@users.sourceforge.net>,
> >       Jostein Kjønigsen <jostein@secure.kjonigsen.net>,
> >       Emacs developers <emacs-devel@gnu.org>
> >
> > There is a user on Reddit who pretends that theses latest binaries of
> Emacs run slower on Windows than on
> > Linux.
> > I didn't get a chance yet to give it a try.
> > The test is as follows :
> >
> > - Install Helm from MELPA.
> > - Add this config to the init file, as suggested by Helm page
> >
> > https://www.reddit.com/r/emacs/comments/5e3xpu/emojis_
> in_emacs_intentionally_disabled_for_osx/dabya5i/
> >
> >
> > If anybody has a chance to do the testing. I'm not sure about what helm
> config he is
> > talking about (the full one or the default one).
>
> Helm fires up a lot of subprocesses, and subprocess handling in Emacs
> on MS-Windows is complicated and involves synchronization between
> threads.  Maybe that is at least one reason for slower startup.
>
> Another reason could be intensive file I/O, which is more efficient on
> GNU/Linux (not related to Emacs).
>
> > My guess is that something else than emacs is disturbing his load time
> (antivirus ?).
>
> Yes, antivirus could be yet another reason.
>
> But I agree that without a reproducible recipe, this discussion is a
> bit academic.
>
>

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

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

[Phillip Lord]

Looks pretty comparable to me. Seems pretty clear that the original
issue, anyway, was one of optimisation flags, and glad that it was
relatively simple to solve.

Phil


Fabrice Popineau <fabrice.popineau@centralesupelec.fr> writes:
> One can object that the Ubuntu provided by WSL is not the Real Thing (TM),
> but that should be close enough.
> So I don't see a real difference here.
>
> Regards,
>
> Fabrice
>
>
> 2016-11-30 15:48 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>
>> > From: Fabrice Popineau <fabrice.popineau@centralesupelec.fr>
>> > Date: Wed, 30 Nov 2016 08:56:09 +0100
>> > Cc: jostein@kjonigsen.net, Eli Zaretskii <eliz@gnu.org>,
>> >       Noam Postavsky <npostavs@users.sourceforge.net>,
>> >       Jostein Kjønigsen <jostein@secure.kjonigsen.net>,
>> >       Emacs developers <emacs-devel@gnu.org>
>> >
>> > There is a user on Reddit who pretends that theses latest binaries of
>> Emacs run slower on Windows than on
>> > Linux.
>> > I didn't get a chance yet to give it a try.
>> > The test is as follows :
>> >
>> > - Install Helm from MELPA.
>> > - Add this config to the init file, as suggested by Helm page
>> >
>> > https://www.reddit.com/r/emacs/comments/5e3xpu/emojis_
>> in_emacs_intentionally_disabled_for_osx/dabya5i/
>> >
>> >
>> > If anybody has a chance to do the testing. I'm not sure about what helm
>> config he is
>> > talking about (the full one or the default one).
>>
>> Helm fires up a lot of subprocesses, and subprocess handling in Emacs
>> on MS-Windows is complicated and involves synchronization between
>> threads.  Maybe that is at least one reason for slower startup.
>>
>> Another reason could be intensive file I/O, which is more efficient on
>> GNU/Linux (not related to Emacs).
>>
>> > My guess is that something else than emacs is disturbing his load time
>> (antivirus ?).
>>
>> Yes, antivirus could be yet another reason.
>>
>> But I agree that without a reproducible recipe, this discussion is a
>> bit academic.
>>
>>

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

[jsj.register]

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

Hi,

I encountered huge lags when using org mode (detailed below) on build “emacs-25.1-2-x86_64-w64-mingw32.zip” with “emacs-25-x86_64-deps.zip” (from ftp.gnu.org).
With the same configuration and the same org file, everything is fine on Mac (emacs 25) and on Windows (emacs 24.5), so I think I might post is here. I am sorry if this is the wrong place.

Reproducing it is a little bit tricky.
It seems to happen when certain utf8 symbols are displayed in the buffer.
By saying "certain utf8 symbols”, I refer to those that are not with the common width, so it depends on the font you are using.
What I did is the following.

I am using the latest org mode (version 9) and have turned on “org-pretty-entities” , which replaces some latex codes (eg. \alpha) with their corresponding utf-8 symbols.
The font I use in emacs is “Hack”. With this font, greek letters are all OK, they have the same width as the English letters.
One example to show the lag is “\gg”.
Simply open an org file and put in “\gg” followed by a space and some other letters. “\gg” will be displayed as a utf8 symbol.
Then try to move the cursor quickly. You should experience huge lags.

Any help is appreciated.

Best,
jsj

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

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

[Richard Copley]

On 9 January 2017 at 06:33,  <jsj.register@gmail.com> wrote:
> I encountered huge lags when using org mode (detailed below) on build
> “emacs-25.1-2-x86_64-w64-mingw32.zip” with “emacs-25-x86_64-deps.zip” (from
> ftp.gnu.org).
>
> With the same configuration and the same org file, everything is fine on Mac
> (emacs 25) and on Windows (emacs 24.5), so I think I might post is here. I
> am sorry if this is the wrong place.
>
>
>
> Reproducing it is a little bit tricky.
>
> It seems to happen when certain utf8 symbols are displayed in the buffer.
>
> By saying "certain utf8 symbols”, I refer to those that are not with the
> common width, so it depends on the font you are using.
>
> What I did is the following.
>
>
>
> I am using the latest org mode (version 9) and have turned on
> “org-pretty-entities” , which replaces some latex codes (eg. \alpha) with
> their corresponding utf-8 symbols.
>
> The font I use in emacs is “Hack”. With this font, greek letters are all OK,
> they have the same width as the English letters.
>
> One example to show the lag is “\gg”.
>
> Simply open an org file and put in “\gg” followed by a space and some other
> letters. “\gg” will be displayed as a utf8 symbol.
>
> Then try to move the cursor quickly. You should experience huge lags.

Try installing the Symbola font, if you don't already have it.

(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25279)

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

[Nikolay Kudryavtsev]

It's probably another case of 24565 aka 15876.

Try setting inhibit-compacting-font-caches to t, if you're using 
something newer than 25.1 release.

For 25.1 you can replace default fontset for a range of characters like 
this:

(set-fontset-font t '(#x21d2 . #x21d2) (font-spec :family "FreeSerif"))

-- 
Best Regards,
Nikolay Kudryavtsev

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

[jsj.register]

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

Thanks for the suggestion and the information.
Problem solved.

jsj

From: Richard Copley
Sent: Sunday, January 8, 2017 11:40 PM
To: jsj.register@gmail.com
Cc: phillip.lord@russet.org.uk; emacs-devel@gnu.org
Subject: Re: Regarding performance issues with the Emacs 25.1 Windows-build

On 9 January 2017 at 06:33,  <jsj.register@gmail.com> wrote:
> I encountered huge lags when using org mode (detailed below) on build
> “emacs-25.1-2-x86_64-w64-mingw32.zip” with “emacs-25-x86_64-deps.zip” (from
> ftp.gnu.org).
>
> With the same configuration and the same org file, everything is fine on Mac
> (emacs 25) and on Windows (emacs 24.5), so I think I might post is here. I
> am sorry if this is the wrong place.
>
>
>
> Reproducing it is a little bit tricky.
>
> It seems to happen when certain utf8 symbols are displayed in the buffer.
>
> By saying "certain utf8 symbols”, I refer to those that are not with the
> common width, so it depends on the font you are using.
>
> What I did is the following.
>
>
>
> I am using the latest org mode (version 9) and have turned on
> “org-pretty-entities” , which replaces some latex codes (eg. \alpha) with
> their corresponding utf-8 symbols.
>
> The font I use in emacs is “Hack”. With this font, greek letters are all OK,
> they have the same width as the English letters.
>
> One example to show the lag is “\gg”.
>
> Simply open an org file and put in “\gg” followed by a space and some other
> letters. “\gg” will be displayed as a utf8 symbol.
>
> Then try to move the cursor quickly. You should experience huge lags.

Try installing the Symbola font, if you don't already have it.

(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25279)


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

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

[jsj.register]

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

Thanks for pointing to the two issues.
Problem is solved with font symbola.

jsj


From: Nikolay Kudryavtsev
Sent: Sunday, January 8, 2017 11:57 PM
To: jsj.register@gmail.com; phillip.lord@russet.org.uk; emacs-devel@gnu.org
Subject: Re: Regarding performance issues with the Emacs 25.1 Windows-build

It's probably another case of 24565 aka 15876.

Try setting inhibit-compacting-font-caches to t, if you're using 
something newer than 25.1 release.

For 25.1 you can replace default fontset for a range of characters like 
this:

(set-fontset-font t '(#x21d2 . #x21d2) (font-spec :family "FreeSerif"))

-- 
Best Regards,
Nikolay Kudryavtsev



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