very different start up for emacs master compared with 3 month ago

very different start up for emacs master compared with 3 month ago

[Uwe Brauer]

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 

Re: very different start up for emacs master compared with 3 month ago

[Eli Zaretskii]

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

[SOLVED] (was: very different start up for emacs master compared with 3 month ago)

[Uwe Brauer]

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

Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)

[Eli Zaretskii]

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

Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)

[otadmor .]

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

Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)

[Eli Zaretskii]

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

Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)

[otadmor .]

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

Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)

[Eli Zaretskii]

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

Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)

[otadmor .]

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

Re: [SOLVED] (was: very different start up for emacs master compared with 3 month ago)

[Eli Zaretskii]

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