bug#24720: Performance impact of -no-pie

bug#24720: Performance impact of -no-pie

[Paul Eggert]

(The rest of this message is copied from Alex's email archived at 
<http://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00451.html>.)

After being forced to add -no-pie to my CFLAGS in order to build Emacs with a recent GCC, my startup time for my whole config (with -nw) has increased from ~1 second to ~2 seconds.

The startup time for `emacs -Q -nw` went up from about 0.07s to 0.14s; again it's about twice as slow.

The -Q time doesn't worry me, but the extra second for my main configuration isn't pleasant.

Is such a performance impact expected? If so, is there a plan to regain the old speed?

bug#24720: Performance impact of -no-pie

[Paul Eggert]

> Is such a performance impact expected? If so, is there a plan to regain the old speed?

No, such a performance change is not expected.

Can you reproduce the problem with the emacs-25 or master branches, 
without manually adding -no-pie to CFLAGS? The bleeding-edge versions of 
Emacs attack the problem in a slightly different way, which might affect 
performance less.

If you still see a performance problem, can you narrow it down, e.g., by 
configuring it with --enable-profiling and seeing where the extra cycles 
are going?

bug#24720: Performance impact of -no-pie

[Alex]

Paul Eggert <eggert@cs.ucla.edu> writes:

>> Is such a performance impact expected? If so, is there a plan to regain the
> old speed?
>
> No, such a performance change is not expected.
>
> Can you reproduce the problem with the emacs-25 or master branches, without
> manually adding -no-pie to CFLAGS? The bleeding-edge versions of Emacs attack
> the problem in a slightly different way, which might affect performance less.
>
> If you still see a performance problem, can you narrow it down, e.g., by
> configuring it with --enable-profiling and seeing where the extra cycles are
> going?

Ah, I see. It looks like the bleeding-edge versions add -no-pie to
LDFLAGS instead of CFLAGS. Doing the same thing myself both to those
versions and the 25.1 tarball (which is what I was using before) now
results in the same performance as before, within error.

Is it a bug that adding -no-pie to CFLAGS slows startup and runtime
performance by a factor of 2?

I would have expected that -no-pie would generally be faster compared to
-pie. Is that not the case?

Thanks.

bug#24720: Performance impact of -no-pie

[Glenn Morris]

All that adding -no-pie does is restore the old default behaviour.
It therefore makes no sense for it to cause a slowdown.
I'm going to guess that when you set it via CFLAGS, you lost the -O2
that is otherwise part of the default CFLAGS. M-x report-emacs-bug
includes information that would probably have made this obvious from the
outset. Check the setting of CFLAGS in src/Makefile.

bug#24720: Performance impact of -no-pie

[Paul Eggert]

On 10/18/2016 08:59 AM, Glenn Morris wrote:
> I'm going to guess that when you set it via CFLAGS, you lost the -O2
> that is otherwise part of the default CFLAGS.

Yes, that sounds quite plausible. Thanks for the diagnosis. Closing the bug.

bug#24720: Performance impact of -no-pie

[Alex]

Glenn Morris <rgm@gnu.org> writes:

> All that adding -no-pie does is restore the old default behaviour.
> It therefore makes no sense for it to cause a slowdown.

That makes sense.

> I'm going to guess that when you set it via CFLAGS, you lost the -O2
> that is otherwise part of the default CFLAGS.

That's indeed the case. I thought that specifying it when calling
./configure would have just added to the default CFLAGS instead of
overwriting it. Sorry for the false report.

> M-x report-emacs-bug includes information that would probably have
> made this obvious from the outset. Check the setting of CFLAGS in
> src/Makefile.

No, without specifying any CFLAGS manually, report-emacs-bug doesn't
mention any configuration details. This appears to be because
system-configuration-options is empty in that case.

Only when manually specifying flags does report-emacs-bug show the
configuration option section.

I can see what the CFLAGS are in src/Makefile, thanks. Though it might
be nice if I could see these at the Elisp level even when they're the
default.

bug#24720: Performance impact of -no-pie

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Date: Tue, 18 Oct 2016 22:41:02 -0600
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 24720@debbugs.gnu.org
> 
> I can see what the CFLAGS are in src/Makefile, thanks. Though it might
> be nice if I could see these at the Elisp level even when they're the
> default.

The default switches are known, so they don't need to be spelled out
in the report.  It's the non-default ones that needs to be shown.

bug#24720: Performance impact of -no-pie

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Date: Tue, 18 Oct 2016 22:41:02 -0600
>> Cc: Paul Eggert <eggert@cs.ucla.edu>, 24720@debbugs.gnu.org
>> 
>> I can see what the CFLAGS are in src/Makefile, thanks. Though it might
>> be nice if I could see these at the Elisp level even when they're the
>> default.
>
> The default switches are known, so they don't need to be spelled out
> in the report.  It's the non-default ones that needs to be shown.

I agree that they don't need to be in the report, but just having them
in a variable (e.g. system-configuration-options) would make it easier
for users to see what the default switches are.

For example, I would have compared system-configuration-options between
the slow and fast builds and noticed that the fast build had '-O2' while
the slow one didn't, and this report wouldn't have been filed.

bug#24720: Performance impact of -no-pie

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: rgm@gnu.org,  eggert@cs.ucla.edu,  24720@debbugs.gnu.org
> Date: Wed, 19 Oct 2016 13:45:47 -0600
> 
> > The default switches are known, so they don't need to be spelled out
> > in the report.  It's the non-default ones that needs to be shown.
> 
> I agree that they don't need to be in the report, but just having them
> in a variable (e.g. system-configuration-options) would make it easier
> for users to see what the default switches are.
> 
> For example, I would have compared system-configuration-options between
> the slow and fast builds and noticed that the fast build had '-O2' while
> the slow one didn't, and this report wouldn't have been filed.

You have that information in config.log, so I'm unsure why you
couldn't find it if you looked for it.

bug#24720: Performance impact of -no-pie

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: rgm@gnu.org,  eggert@cs.ucla.edu,  24720@debbugs.gnu.org
>> Date: Wed, 19 Oct 2016 13:45:47 -0600
>> 
>> > The default switches are known, so they don't need to be spelled out
>> > in the report.  It's the non-default ones that needs to be shown.
>> 
>> I agree that they don't need to be in the report, but just having them
>> in a variable (e.g. system-configuration-options) would make it easier
>> for users to see what the default switches are.
>> 
>> For example, I would have compared system-configuration-options between
>> the slow and fast builds and noticed that the fast build had '-O2' while
>> the slow one didn't, and this report wouldn't have been filed.
>
> You have that information in config.log, so I'm unsure why you
> couldn't find it if you looked for it.

Yes, in this case I could have looked in there, but that file is
overwritten with every ./configure, right? That means there's no
guarantee that what's listed there is for a given Emacs build.

I think that configuration options should be tied to, and viewable
through, Emacs regardless of the value it's set to. If report-emacs-bugs
needs to know when to hide the options, then perhaps a new variable
could be introduced for that purpose.

bug#24720: Performance impact of -no-pie

[Alex]

Alex <agrambot@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Alex <agrambot@gmail.com>
>>> Cc: rgm@gnu.org,  eggert@cs.ucla.edu,  24720@debbugs.gnu.org
>>> Date: Wed, 19 Oct 2016 13:45:47 -0600
>>> 
>>> > The default switches are known, so they don't need to be spelled out
>>> > in the report.  It's the non-default ones that needs to be shown.
>>> 
>>> I agree that they don't need to be in the report, but just having them
>>> in a variable (e.g. system-configuration-options) would make it easier
>>> for users to see what the default switches are.
>>> 
>>> For example, I would have compared system-configuration-options between
>>> the slow and fast builds and noticed that the fast build had '-O2' while
>>> the slow one didn't, and this report wouldn't have been filed.
>>
>> You have that information in config.log, so I'm unsure why you
>> couldn't find it if you looked for it.
>
> Yes, in this case I could have looked in there, but that file is
> overwritten with every ./configure, right? That means there's no
> guarantee that what's listed there is for a given Emacs build.
>
> I think that configuration options should be tied to, and viewable
> through, Emacs regardless of the value it's set to. If report-emacs-bugs
> needs to know when to hide the options, then perhaps a new variable
> could be introduced for that purpose.

For example, in configure.ac, if the block that calculates
emacs_config_options was moved to the bottom before

AC_DEFINE_UNQUOTED(EMACS_CONFIG_OPTIONS, "${emacs_config_options}",
		   [Define to the options passed to configure.])

then system-configuration-options is:

"dummy pkg-config 'CFLAGS=-g3 -O2' 'CPPFLAGS=  ' 'LDFLAGS= '"

I'm not sure what 'dummy pkg-config' is doing there, but otherwise I
think that it would be nice to have this as the default.

bug#24720: Performance impact of -no-pie

[Cesar Quiroz]

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

Another data point: Ubuntu 16.10 offers emacs 24.5 in /usr/bin/emacs.  It
is built with -no-pie. Could you check if /usr/bin/emacs also feels slow?


--César

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