* bug#24720: Performance impact of -no-pie @ 2016-10-17 20:18 Paul Eggert [not found] ` <handler.24720.B.147673554717923.ack@debbugs.gnu.org> 2016-10-18 5:54 ` Cesar Quiroz 0 siblings, 2 replies; 12+ messages in thread From: Paul Eggert @ 2016-10-17 20:18 UTC (permalink / raw) To: 24720; +Cc: Alex (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? ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <handler.24720.B.147673554717923.ack@debbugs.gnu.org>]
* bug#24720: Performance impact of -no-pie [not found] ` <handler.24720.B.147673554717923.ack@debbugs.gnu.org> @ 2016-10-17 20:26 ` Paul Eggert 2016-10-18 4:06 ` Alex 0 siblings, 1 reply; 12+ messages in thread From: Paul Eggert @ 2016-10-17 20:26 UTC (permalink / raw) To: Alex; +Cc: 24720 > 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-17 20:26 ` Paul Eggert @ 2016-10-18 4:06 ` Alex 2016-10-18 15:59 ` Glenn Morris 0 siblings, 1 reply; 12+ messages in thread From: Alex @ 2016-10-18 4:06 UTC (permalink / raw) To: Paul Eggert; +Cc: 24720 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-18 4:06 ` Alex @ 2016-10-18 15:59 ` Glenn Morris 2016-10-18 16:21 ` Paul Eggert 2016-10-19 4:41 ` Alex 0 siblings, 2 replies; 12+ messages in thread From: Glenn Morris @ 2016-10-18 15:59 UTC (permalink / raw) To: Alex; +Cc: Paul Eggert, 24720 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-18 15:59 ` Glenn Morris @ 2016-10-18 16:21 ` Paul Eggert 2016-10-19 4:41 ` Alex 1 sibling, 0 replies; 12+ messages in thread From: Paul Eggert @ 2016-10-18 16:21 UTC (permalink / raw) To: Glenn Morris, Alex; +Cc: 24720-done 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-18 15:59 ` Glenn Morris 2016-10-18 16:21 ` Paul Eggert @ 2016-10-19 4:41 ` Alex 2016-10-19 7:04 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: Alex @ 2016-10-19 4:41 UTC (permalink / raw) To: Glenn Morris; +Cc: Paul Eggert, 24720 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-19 4:41 ` Alex @ 2016-10-19 7:04 ` Eli Zaretskii 2016-10-19 19:45 ` Alex 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2016-10-19 7:04 UTC (permalink / raw) To: Alex; +Cc: eggert, 24720 > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-19 7:04 ` Eli Zaretskii @ 2016-10-19 19:45 ` Alex 2016-10-20 7:04 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Alex @ 2016-10-19 19:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, 24720 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-19 19:45 ` Alex @ 2016-10-20 7:04 ` Eli Zaretskii 2016-10-20 22:13 ` Alex 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2016-10-20 7:04 UTC (permalink / raw) To: Alex; +Cc: eggert, 24720 > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-20 7:04 ` Eli Zaretskii @ 2016-10-20 22:13 ` Alex 2016-10-26 4:30 ` Alex 0 siblings, 1 reply; 12+ messages in thread From: Alex @ 2016-10-20 22:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, 24720 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-20 22:13 ` Alex @ 2016-10-26 4:30 ` Alex 0 siblings, 0 replies; 12+ messages in thread From: Alex @ 2016-10-26 4:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, 24720 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#24720: Performance impact of -no-pie 2016-10-17 20:18 bug#24720: Performance impact of -no-pie Paul Eggert [not found] ` <handler.24720.B.147673554717923.ack@debbugs.gnu.org> @ 2016-10-18 5:54 ` Cesar Quiroz 1 sibling, 0 replies; 12+ messages in thread From: Cesar Quiroz @ 2016-10-18 5:54 UTC (permalink / raw) To: agrambot; +Cc: 24720 [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-10-26 4:30 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-10-17 20:18 bug#24720: Performance impact of -no-pie Paul Eggert [not found] ` <handler.24720.B.147673554717923.ack@debbugs.gnu.org> 2016-10-17 20:26 ` Paul Eggert 2016-10-18 4:06 ` Alex 2016-10-18 15:59 ` Glenn Morris 2016-10-18 16:21 ` Paul Eggert 2016-10-19 4:41 ` Alex 2016-10-19 7:04 ` Eli Zaretskii 2016-10-19 19:45 ` Alex 2016-10-20 7:04 ` Eli Zaretskii 2016-10-20 22:13 ` Alex 2016-10-26 4:30 ` Alex 2016-10-18 5:54 ` Cesar Quiroz
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.