Extra info about 109170

Extra info about 109170

[Dmitry Antipov]

To whom it may concern, 109170 was surprising. Before it was:

/usr/bin/time:

Done (Total of 1358 files compiled, 41 skipped in 31 directories)
90.78user 0.78system 2:18.91elapsed 65%CPU (0avgtext+0avgdata 72776maxresident)k
0inputs+78928outputs (0major+38242minor)pagefaults 0swaps

/usr/bin/perf:

# Overhead   Command          Shared Object                                      Symbol
# ........  ........  .....................  ..........................................
#
     28.95%     emacs  emacs                  [.] mark_object
     15.03%     emacs  emacs                  [.] exec_byte_code
     11.77%     emacs  emacs                  [.] Fkill_buffer                  ! OUCH !
     10.89%     emacs  emacs                  [.] Fgarbage_collect
      6.42%     emacs  emacs                  [.] oblookup
      5.70%     emacs  emacs                  [.] Fmemq
      1.67%     emacs  emacs                  [.] Fassq
      1.18%     emacs  emacs                  [.] Ffuncall
      1.05%     emacs  emacs                  [.] mark_vectorlike

Now it is:

/usr/bin/time:

Done (Total of 1358 files compiled, 41 skipped in 31 directories)
83.91user 0.77system 2:11.66elapsed 64%CPU (0avgtext+0avgdata 72784maxresident)k
0inputs+78936outputs (0major+38449minor)pagefaults 0swaps

/usr/bin/perf:

# Overhead   Command          Shared Object                                      Symbol
# ........  ........  .....................  ..........................................
#
     33.08%     emacs  emacs                  [.] mark_object
     16.97%     emacs  emacs                  [.] exec_byte_code
     12.58%     emacs  emacs                  [.] Fgarbage_collect
      7.47%     emacs  emacs                  [.] oblookup
      6.79%     emacs  emacs                  [.] Fmemq
      1.90%     emacs  emacs                  [.] Fassq
      1.21%     emacs  emacs                  [.] mark_vectorlike
      1.16%     emacs  emacs                  [.] Ffuncall

Dmitry

Re: Extra info about 109170

[Stefan Monnier]

>     28.95%     emacs  emacs                  [.] mark_object
>     15.03%     emacs  emacs                  [.] exec_byte_code
>     11.77%     emacs  emacs                  [.] Fkill_buffer                  ! OUCH !

Surprising, indeed!
Tho I guess it's due to with-temp-buffer and things like that.
Thanks,


        Stefan

Re: Extra info about 109170

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Sat, 21 Jul 2012 03:04:55 -0400
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> >     28.95%     emacs  emacs                  [.] mark_object
> >     15.03%     emacs  emacs                  [.] exec_byte_code
> >     11.77%     emacs  emacs                  [.] Fkill_buffer  ! OUCH !
> 
> Surprising, indeed!
> Tho I guess it's due to with-temp-buffer and things like that.
> Thanks,

I'd appreciate if someone could explain why are we excited about 8%
speedup, and on top of that in massive byte-compiling (something that
can hardly be described as a frequent operation).  To me, it sounds
like a classic case of premature optimization: speeding up something
that takes 12% of the total time.  Maybe I'm missing something.

Re: Extra info about 109170

[Stefan Monnier]

> I'd appreciate if someone could explain why are we excited about 8%
> speedup, and on top of that in massive byte-compiling (something that
> can hardly be described as a frequent operation).

8% speedup in an actual run of Emacs is a pretty good speed up for such
a small change.


        Stefan

Re: Extra info about 109170

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> Date: Sun, 22 Jul 2012 05:57:20 -0400
> 
> > I'd appreciate if someone could explain why are we excited about 8%
> > speedup, and on top of that in massive byte-compiling (something that
> > can hardly be described as a frequent operation).
> 
> 8% speedup in an actual run of Emacs is a pretty good speed up for such
> a small change.

Any speedup is good.  I just don't see how speeding up kill-buffer is
something people should be using up their time for.  But I guess we
cannot tell people which itch to scratch.

Re: Extra info about 109170

[Stefan Monnier]

>> > I'd appreciate if someone could explain why are we excited about 8%
>> > speedup, and on top of that in massive byte-compiling (something that
>> > can hardly be described as a frequent operation).
>> 8% speedup in an actual run of Emacs is a pretty good speed up for such
>> a small change.
> Any speedup is good.  I just don't see how speeding up kill-buffer is
> something people should be using up their time for.

The purpose was not to speed up kill-buffer but byte-compilation, AFAICT.


        Stefan

Re: Extra info about 109170

[joakim]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> > I'd appreciate if someone could explain why are we excited about 8%
>>> > speedup, and on top of that in massive byte-compiling (something that
>>> > can hardly be described as a frequent operation).
>>> 8% speedup in an actual run of Emacs is a pretty good speed up for such
>>> a small change.
>> Any speedup is good.  I just don't see how speeding up kill-buffer is
>> something people should be using up their time for.
>
> The purpose was not to speed up kill-buffer but byte-compilation, AFAICT.

Sppeding up byte-compilation is useful for us that update elisp packages
a lot. Just my 2 öre.


>
>
>         Stefan

-- 
Joakim Verona

Re: Extra info about 109170

[Nix]

On 23 Jul 2012, Stefan Monnier spake thusly:

>>> > I'd appreciate if someone could explain why are we excited about 8%
>>> > speedup, and on top of that in massive byte-compiling (something that
>>> > can hardly be described as a frequent operation).
>>> 8% speedup in an actual run of Emacs is a pretty good speed up for such
>>> a small change.
>> Any speedup is good.  I just don't see how speeding up kill-buffer is
>> something people should be using up their time for.
>
> The purpose was not to speed up kill-buffer but byte-compilation, AFAICT.

But speaking as someone who just pruned his list of open buffers down
from a thousand-plus, anything that avoids pointless walks through a
list of that length is worthwhile too. :)

(I didn't open most of those: I guess it must be that Semantic's parsing
phase can sometimes find files to scan them and then not close them
again. I'll keep an eye out.)

-- 
NULL && (void)

Re: Extra info about 109170

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 23 Jul 2012 04:55:14 -0400
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> 
> >> > I'd appreciate if someone could explain why are we excited about 8%
> >> > speedup, and on top of that in massive byte-compiling (something that
> >> > can hardly be described as a frequent operation).
> >> 8% speedup in an actual run of Emacs is a pretty good speed up for such
> >> a small change.
> > Any speedup is good.  I just don't see how speeding up kill-buffer is
> > something people should be using up their time for.
> 
> The purpose was not to speed up kill-buffer but byte-compilation, AFAICT.

I was talking about the result, not the purpose.

Re: Extra info about 109170

[Stefan Monnier]

>> >> > I'd appreciate if someone could explain why are we excited about 8%
>> >> > speedup, and on top of that in massive byte-compiling (something that
>> >> > can hardly be described as a frequent operation).
>> >> 8% speedup in an actual run of Emacs is a pretty good speed up for such
>> >> a small change.
>> > Any speedup is good.  I just don't see how speeding up kill-buffer is
>> > something people should be using up their time for.
>> The purpose was not to speed up kill-buffer but byte-compilation, AFAICT.
> I was talking about the result, not the purpose.

The problem was that kill-buffer was taking up more than 10% of the time
of execution, which is simply unjustified.  I only know of 2 ways to fix
such a problem:
- speed up kill-buffer.
- call kill-buffer less often.
(tho I guess you can also "fix" it by slowing down everything else,
but that's not very interesting, is it?).
So unless you mean that the right thing to do was to reduce calls to
kill-buffer, I don't know what else you might have wanted.
And yes, maybe there are too many calls to kill-buffer.


        Stefan

Re: Extra info about 109170

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> Date: Mon, 23 Jul 2012 19:06:53 -0400
> 
> The problem was that kill-buffer was taking up more than 10% of the time
> of execution, which is simply unjustified.  I only know of 2 ways to fix
> such a problem:
> - speed up kill-buffer.
> - call kill-buffer less often.
> (tho I guess you can also "fix" it by slowing down everything else,
> but that's not very interesting, is it?).
> So unless you mean that the right thing to do was to reduce calls to
> kill-buffer, I don't know what else you might have wanted.

I think, if we want to speed up byte compilation, the right thing is
to speed the compilation itself, not buffer-killing whose relevance to
byte compilation is, well, questionable.

Re: Extra info about 109170

[Stefan Monnier]

>> The problem was that kill-buffer was taking up more than 10% of the time
>> of execution, which is simply unjustified.  I only know of 2 ways to fix
>> such a problem:
>> - speed up kill-buffer.
>> - call kill-buffer less often.
>> (tho I guess you can also "fix" it by slowing down everything else,
>> but that's not very interesting, is it?).
>> So unless you mean that the right thing to do was to reduce calls to
>> kill-buffer, I don't know what else you might have wanted.

> I think, if we want to speed up byte compilation, the right thing is
> to speed the compilation itself, not buffer-killing whose relevance to
> byte compilation is, well, questionable.

I'm not sure if that means you disagree with my above analysis (if so,
I don't know with which part), or if you do agree with it but think that
the solution should be to reduce the number of calls to kill-buffer.


        Stefan

Re: Extra info about 109170

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> Date: Tue, 24 Jul 2012 18:11:11 -0400
> 
> >> The problem was that kill-buffer was taking up more than 10% of the time
> >> of execution, which is simply unjustified.  I only know of 2 ways to fix
> >> such a problem:
> >> - speed up kill-buffer.
> >> - call kill-buffer less often.
> >> (tho I guess you can also "fix" it by slowing down everything else,
> >> but that's not very interesting, is it?).
> >> So unless you mean that the right thing to do was to reduce calls to
> >> kill-buffer, I don't know what else you might have wanted.
> 
> > I think, if we want to speed up byte compilation, the right thing is
> > to speed the compilation itself, not buffer-killing whose relevance to
> > byte compilation is, well, questionable.
> 
> I'm not sure if that means you disagree with my above analysis (if so,
> I don't know with which part), or if you do agree with it but think that
> the solution should be to reduce the number of calls to kill-buffer.

I simply don't think we should pay attention to kill-buffer here.  It
takes only 12% of the run time in this case, and is not an important
operation in general to invest efforts in speeding it up.

Re: Extra info about 109170

[Stefan Monnier]

> I simply don't think we should pay attention to kill-buffer here.  It
> takes only 12% of the run time in this case, and is not an important
> operation in general to invest efforts in speeding it up.

To me, this optimization is a "low hanging fruit", which gives you 8% of
speed up for little effort.  I don't know of many such optimizations.


        Stefan