Default compiler optimization level for building dev sources

Default compiler optimization level for building dev sources

[Óscar Fuentes]

I'm using Emacs 25.0.92 on Windows and it seems remarkably slower than
the previous binary. This one was built with a plain config && make
while the previous one had CFLAGS set to -O3 and other extra
optimization flags.

Maybe the build does not turn on optimizations when it detects that the
sources are on a repo. Sorry for asking here instead of checking it
myself but today I have no access to the sources nor the web.

Re: Default compiler optimization level for building dev sources

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 22 Apr 2016 16:17:48 +0200
> 
> I'm using Emacs 25.0.92 on Windows and it seems remarkably slower than
> the previous binary. This one was built with a plain config && make
> while the previous one had CFLAGS set to -O3 and other extra
> optimization flags.

So you are saying that -O2 (that's the default) is significantly
slower than -O3?  That's strange, my experience is that -O3 is
generally not faster than -O2 and sometimes slower.

> Maybe the build does not turn on optimizations when it detects that the
> sources are on a repo. Sorry for asking here instead of checking it
> myself but today I have no access to the sources nor the web.

I don't think so.  The default is -O2, so if you want -O3, you need to
request it by saying "CFLAGS='-O3' ./configure ...".

Do you still have the source directory tree where you b uilt the
previous binary?  If so, please tell what configure-time switches you
used and which compiler switches do you see in src/Makefile.

Re: Default compiler optimization level for building dev sources

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm using Emacs 25.0.92 on Windows and it seems remarkably slower than
>> the previous binary. This one was built with a plain config && make
>> while the previous one had CFLAGS set to -O3 and other extra
>> optimization flags.
>
> So you are saying that -O2 (that's the default) is significantly
> slower than -O3?

No, I'm saying that this binary feels quite slower than the previous
one.

> That's strange, my experience is that -O3 is
> generally not faster than -O2 and sometimes slower.

No arguing here. The cause must be elsewhere. The previous binary was
one year old and the current one is from a few days old master but I
doubt that such performance deterioration was caused by the introduced
changes with nobody noticing until now.

I need to investigate further.

>> Maybe the build does not turn on optimizations when it detects that the
>> sources are on a repo. Sorry for asking here instead of checking it
>> myself but today I have no access to the sources nor the web.
>
> I don't think so.  The default is -O2, so if you want -O3, you need to
> request it by saying "CFLAGS='-O3' ./configure ...".
>
> Do you still have the source directory tree where you b uilt the
> previous binary?  If so, please tell what configure-time switches you
> used and which compiler switches do you see in src/Makefile.

I *think* that the build dir is still around, but I have no access to
that VM for now. I trust you on the default CFLAGS, but maybe
makepkg-mingw (this is the MSYS2 way of building packages) did something
on its own. I'll check the Makefile and re-launch the build with some
flag for showing the compile command instead of just `CC foo.c' (I guess
that `make VERBOSE=1' will do.)

Thank you.

Re: Default compiler optimization level for building dev sources

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

> I'm using Emacs 25.0.92 on Windows and it seems remarkably slower than the
> previous binary. This one was built with a plain config && make while the
> previous one had CFLAGS set to -O3 and other extra optimization flags.

What flavor of slowness do you experience?

One thing I've noticed with 25.0.92 and OS X is that Emacs 25 can be very
"pausy". That is, I'll do something (even just switch buffers), and suddenly
Emacs is locked for about 5-10 seconds, with absolutely no indication before
or after of what is happening.  Maybe it's GC?

Especially with ERC, this is quite noticeable because it happens in the middle
of a conversation. In Emacs 24 I never experienced this much stalling (just a
little bit).

However, this has been impossible to track down thus far; but I wonder if what
you're seeing is at all similar.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Default compiler optimization level for building dev sources

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Fri, 22 Apr 2016 10:56:55 -0700
> Cc: emacs-devel@gnu.org
> 
> One thing I've noticed with 25.0.92 and OS X is that Emacs 25 can be very
> "pausy". That is, I'll do something (even just switch buffers), and suddenly
> Emacs is locked for about 5-10 seconds, with absolutely no indication before
> or after of what is happening.  Maybe it's GC?

Sounds like some idle timer that does some expensive job.

Re: Default compiler optimization level for building dev sources

[Andreas Schwab]

John Wiegley <jwiegley@gmail.com> writes:

> Maybe it's GC?

Set garbage-collection-messages to find out.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Default compiler optimization level for building dev sources

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> I'm using Emacs 25.0.92 on Windows and it seems remarkably slower than the
>> previous binary. This one was built with a plain config && make while the
>> previous one had CFLAGS set to -O3 and other extra optimization flags.
>
> What flavor of slowness do you experience?

Certain operations which used to take a somewhat annoying long time now
are almost unbearable. Mostly Magit-related.

> One thing I've noticed with 25.0.92 and OS X is that Emacs 25 can be very
> "pausy". That is, I'll do something (even just switch buffers), and suddenly
> Emacs is locked for about 5-10 seconds, with absolutely no indication before
> or after of what is happening.  Maybe it's GC?

I see something like this on VMs, but for now I tend to attribute the
problem to the VM itself, not to Emacs proper.

> Especially with ERC, this is quite noticeable because it happens in the middle
> of a conversation. In Emacs 24 I never experienced this much stalling (just a
> little bit).
>
> However, this has been impossible to track down thus far; but I wonder if what
> you're seeing is at all similar.

I don't think so. The problems I observe are more related to a general
slow down than to occassional unresponsiveness.

Re: Default compiler optimization level for building dev sources

[John Mastro]

Óscar Fuentes <ofv@wanadoo.es> wrote:
> Certain operations which used to take a somewhat annoying long time now
> are almost unbearable. Mostly Magit-related.

Magit has some useful notes regarding performance[1], including for
Windows specifically.

(I don't mean to comment on whether the performance problems are with
Emacs and/or Magit, only to point it out in case you haven't seen it).

[1]: https://magit.vc/manual/magit/Performance.html

-- 
          John

Re: Default compiler optimization level for building dev sources

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Fri, 22 Apr 2016 13:25:13 -0700
> 
> Magit has some useful notes regarding performance[1], including for
> Windows specifically.
> 
> (I don't mean to comment on whether the performance problems are with
> Emacs and/or Magit, only to point it out in case you haven't seen it).
> 
> [1]: https://magit.vc/manual/magit/Performance.html

When was that last updated/verified?  I think the information there is
mostly outdated.  E.g., the stackoverflow question and advice refers
to Git 1.7.x, and definitely describes a broken setup ("cd" taking 8
to 25 sec? come on, be serious!).

The only factor I'm aware of for slow startup of Git on Windows is due
to MSYS Bash and other MSYS commands that are run by those Git
commands that are implemented as shell or Perl scripts.  MSYS is a
fork of Cygwin, which is known for this issue (emulating 'fork' on
Windows is expensive).  Git commands that don't invoke Bash or Perl
should be fast enough on Windows, AFAIK.