* very different start up for emacs master compared with 3 month ago
@ 2019-08-09 15:47 Uwe Brauer
2019-08-09 16:05 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Uwe Brauer @ 2019-08-09 15:47 UTC (permalink / raw)
To: emacs-devel
Hi
My standard configuration is this
./configure --prefix=/opt/emacs27 --with-x-toolkit=athena --with-mailutils
I complied a version from 24 April and a very recent version (since Lars
implemented the scaling image feature). For emacs -q there is no
difference in the start up, but if I load my usual init files there is a huge difference.
Here is the table
#+begin_src
| Version | init file | without init |
|------------------------------------------+-----------+--------------|
| b06917a4912a60402025286d07d4a195749245c4 | 50 sec | 1-2 sec |
| 1d75604eaded6a8482d28d57bc8e6a4d99d5caee | 15 sec | 1-2 sec |
#+end_src
Any idea whats up?
How can I debug this?
Uwe Brauer
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: very different start up for emacs master compared with 3 month ago
2019-08-09 15:47 very different start up for emacs master compared with 3 month ago Uwe Brauer
@ 2019-08-09 16:05 ` Eli Zaretskii
2019-08-13 10:51 ` [SOLVED] (was: very different start up for emacs master compared with 3 month ago) Uwe Brauer
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2019-08-09 16:05 UTC (permalink / raw)
To: Uwe Brauer; +Cc: emacs-devel
> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Fri, 09 Aug 2019 17:47:03 +0200
>
> | Version | init file | without init |
> |------------------------------------------+-----------+--------------|
> | b06917a4912a60402025286d07d4a195749245c4 | 50 sec | 1-2 sec |
> | 1d75604eaded6a8482d28d57bc8e6a4d99d5caee | 15 sec | 1-2 sec |
>
> #+end_src
>
>
> Any idea whats up?
>
> How can I debug this?
Bisect your customizations to see which part takes the lion's share of
the time, I'd say.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [SOLVED] (was: very different start up for emacs master compared with 3 month ago)
2019-08-09 16:05 ` Eli Zaretskii
@ 2019-08-13 10:51 ` Uwe Brauer
2019-08-13 14:29 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Uwe Brauer @ 2019-08-13 10:51 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>> From: Uwe Brauer <oub@mat.ucm.es>
>> Date: Fri, 09 Aug 2019 17:47:03 +0200
>>
>> | Version | init file | without init |
>> |------------------------------------------+-----------+--------------|
>> | b06917a4912a60402025286d07d4a195749245c4 | 50 sec | 1-2 sec |
>> | 1d75604eaded6a8482d28d57bc8e6a4d99d5caee | 15 sec | 1-2 sec |
>>
>> #+end_src
>>
>>
>> Any idea whats up?
>>
>> How can I debug this?
> Bisect your customizations to see which part takes the lion's share of
> the time, I'd say.
It was my fault. I bisected different commits (using mercurial)
My configuration script was
./configure CFLAGS='-O0 -g3' --enable-checking='yes,glyphs' --enable-check-lisp-object-type --prefix=/opt/emacs27 --with-x-toolkit=athena --with-mailutils
Which slowed down loading considerably (must have needed that some time
ago)
I switched back to
./configure --prefix=/opt/emacs27 --with-x-toolkit=athena --with-mailutils
And everything was back to normal. Sorry.
At least now I know how to modify emacs-repository-version, in order to
include mercurial, but as it seems there is anyhow no mercurial hacker
around needing this.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)
2019-08-13 10:51 ` [SOLVED] (was: very different start up for emacs master compared with 3 month ago) Uwe Brauer
@ 2019-08-13 14:29 ` Eli Zaretskii
2019-08-13 18:46 ` otadmor .
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2019-08-13 14:29 UTC (permalink / raw)
To: Uwe Brauer; +Cc: emacs-devel
> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Tue, 13 Aug 2019 12:51:33 +0200
>
> >> | Version | init file | without init |
> >> |------------------------------------------+-----------+--------------|
> >> | b06917a4912a60402025286d07d4a195749245c4 | 50 sec | 1-2 sec |
> >> | 1d75604eaded6a8482d28d57bc8e6a4d99d5caee | 15 sec | 1-2 sec |
> >>
> >> #+end_src
> >>
> >>
> >> Any idea whats up?
> >>
> >> How can I debug this?
>
> > Bisect your customizations to see which part takes the lion's share of
> > the time, I'd say.
>
> It was my fault. I bisected different commits (using mercurial)
>
> My configuration script was
>
>
> ./configure CFLAGS='-O0 -g3' --enable-checking='yes,glyphs' --enable-check-lisp-object-type --prefix=/opt/emacs27 --with-x-toolkit=athena --with-mailutils
OK, an unoptimized build is expected to be about 2.5 to 3 times slower
than the optimized one.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)
2019-08-13 14:29 ` Eli Zaretskii
@ 2019-08-13 18:46 ` otadmor .
2019-08-13 18:55 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: otadmor . @ 2019-08-13 18:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Uwe Brauer, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
When compiling emacs for daily use is it better to compile with -O? Or
without -O at all?
Which optimization level is suggested?
On Tue, Aug 13, 2019, 17:29 Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Uwe Brauer <oub@mat.ucm.es>
> > Date: Tue, 13 Aug 2019 12:51:33 +0200
> >
> > >> | Version | init file | without
> init |
> > >>
> |------------------------------------------+-----------+--------------|
> > >> | b06917a4912a60402025286d07d4a195749245c4 | 50 sec | 1-2 sec
> |
> > >> | 1d75604eaded6a8482d28d57bc8e6a4d99d5caee | 15 sec | 1-2 sec
> |
> > >>
> > >> #+end_src
> > >>
> > >>
> > >> Any idea whats up?
> > >>
> > >> How can I debug this?
> >
> > > Bisect your customizations to see which part takes the lion's share
> of
> > > the time, I'd say.
> >
> > It was my fault. I bisected different commits (using mercurial)
> >
> > My configuration script was
> >
> >
> > ./configure CFLAGS='-O0 -g3' --enable-checking='yes,glyphs'
> --enable-check-lisp-object-type --prefix=/opt/emacs27
> --with-x-toolkit=athena --with-mailutils
>
> OK, an unoptimized build is expected to be about 2.5 to 3 times slower
> than the optimized one.
>
>
[-- Attachment #2: Type: text/html, Size: 1885 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)
2019-08-13 18:46 ` otadmor .
@ 2019-08-13 18:55 ` Eli Zaretskii
2019-08-13 21:10 ` otadmor .
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2019-08-13 18:55 UTC (permalink / raw)
To: otadmor .; +Cc: oub, emacs-devel
> From: "otadmor ." <otadmor@gmail.com>
> Date: Tue, 13 Aug 2019 21:46:48 +0300
> Cc: Uwe Brauer <oub@mat.ucm.es>, emacs-devel@gnu.org
>
> When compiling emacs for daily use is it better to compile with -O? Or without -O at all?
> Which optimization level is suggested?
Using -O0 produces a binary that's slower, but if it crashes or you
need to debug it, the information you can report is more full and
reliable. Letting the build use the default optimization produces a
faster program, but it's harder to debug.
What to do is up to you. I debug the development version of Emacs
quite a lot, so I always build the development snapshots with -O0.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)
2019-08-13 18:55 ` Eli Zaretskii
@ 2019-08-13 21:10 ` otadmor .
2019-08-14 2:36 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: otadmor . @ 2019-08-13 21:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: oub, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
Are there any known issues with Ofast?
On Tue, Aug 13, 2019, 21:56 Eli Zaretskii <eliz@gnu.org> wrote:
> > From: "otadmor ." <otadmor@gmail.com>
> > Date: Tue, 13 Aug 2019 21:46:48 +0300
> > Cc: Uwe Brauer <oub@mat.ucm.es>, emacs-devel@gnu.org
> >
> > When compiling emacs for daily use is it better to compile with -O? Or
> without -O at all?
> > Which optimization level is suggested?
>
> Using -O0 produces a binary that's slower, but if it crashes or you
> need to debug it, the information you can report is more full and
> reliable. Letting the build use the default optimization produces a
> faster program, but it's harder to debug.
>
> What to do is up to you. I debug the development version of Emacs
> quite a lot, so I always build the development snapshots with -O0.
>
[-- Attachment #2: Type: text/html, Size: 1361 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)
2019-08-13 21:10 ` otadmor .
@ 2019-08-14 2:36 ` Eli Zaretskii
2019-08-14 5:19 ` otadmor .
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2019-08-14 2:36 UTC (permalink / raw)
To: otadmor .; +Cc: oub, emacs-devel
> From: "otadmor ." <otadmor@gmail.com>
> Date: Wed, 14 Aug 2019 00:10:50 +0300
> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
>
> Are there any known issues with Ofast?
Yes, they are described in the GCC manual.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)
2019-08-14 2:36 ` Eli Zaretskii
@ 2019-08-14 5:19 ` otadmor .
2019-08-14 14:24 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: otadmor . @ 2019-08-14 5:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: oub, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
I meant issues of emacs with Ofast. If some things are known to be broken
on emacs with this. I'm not sure gcc man will give notes on emacs.
On Wed, Aug 14, 2019, 05:36 Eli Zaretskii <eliz@gnu.org> wrote:
> > From: "otadmor ." <otadmor@gmail.com>
> > Date: Wed, 14 Aug 2019 00:10:50 +0300
> > Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> >
> > Are there any known issues with Ofast?
>
> Yes, they are described in the GCC manual.
>
[-- Attachment #2: Type: text/html, Size: 956 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)
2019-08-14 5:19 ` otadmor .
@ 2019-08-14 14:24 ` Eli Zaretskii
0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2019-08-14 14:24 UTC (permalink / raw)
To: otadmor .; +Cc: oub, emacs-devel
> From: "otadmor ." <otadmor@gmail.com>
> Date: Wed, 14 Aug 2019 08:19:19 +0300
> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
>
> I meant issues of emacs with Ofast. If some things are known to be broken on emacs with this. I'm not sure
> gcc man will give notes on emacs.
That option's downsides are not related specifically to Emacs. The
option causes GCC to use optimizations that can produce invalid
programs. I don't think anyone has tried it with Emacs, and for a
very good reason: it is not intended for general purpose programs. I
personally advise to stay away of it, except when building programs
where you understand very well the floating-point numerical aspects of
every single line of code.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-08-14 14:24 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-08-09 15:47 very different start up for emacs master compared with 3 month ago Uwe Brauer
2019-08-09 16:05 ` Eli Zaretskii
2019-08-13 10:51 ` [SOLVED] (was: very different start up for emacs master compared with 3 month ago) Uwe Brauer
2019-08-13 14:29 ` Eli Zaretskii
2019-08-13 18:46 ` otadmor .
2019-08-13 18:55 ` Eli Zaretskii
2019-08-13 21:10 ` otadmor .
2019-08-14 2:36 ` Eli Zaretskii
2019-08-14 5:19 ` otadmor .
2019-08-14 14:24 ` Eli Zaretskii
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.