Performance regression in CVS HEAD's *compilation* buffer

Performance regression in CVS HEAD's *compilation* buffer

[sand]

I updated my CVS tree to HEAD today (2009-02-03, around noon PST),
compiled it, and started using it.  My previous sync had been around
2008-12-01.  During that interval, the performance of inserting long
lines into the *compilation* buffer has dropped by an order of
magnitude.

Here's a simple test case to reproduce:

* In *scratch*, create 96 lines of "x" characters, 64 characters wide.

  <f3> C-u 64 C-u x C-m <f4>
  C-u 95 <f4>

* Put them all onto a single line.

  M-<
  C-u 10000 C-x f
  M-q

* Put an "echo" on the front to make it an invokable command, and copy
  it to a register.

  e c h o <SPC>
  C-x h
  C-x r x c

* Run `compile' with that command:

  M-x compile
  C-a C-k
  C-x r i c
  <RET>

It used to take on the order of 10 seconds to complete.  For example,
on my home machine:

  -*- mode: compilation; default-directory: "~/" -*-
  Compilation started at Tue Feb  3 19:28:40

  echo [...]

  [...]

  Compilation finished at Tue Feb  3 19:28:50

(Output elided.)  With CVS HEAD, this takes well over a minute.  In
both cases, Emacs is completely unresponsive during this display
period.  This is a big problem when running Make with extremely long
(~6kB) output lines.

My home machine is a Debian box running a snapshot of CVS HEAD from
2009-01-11, and I'm unable to reproduce it here, so the performance
drop seems to happened sometime between the 11th and today.

Thanks,

Derek

Re: Performance regression in CVS HEAD's *compilation* buffer

[Stefan Monnier]

> I updated my CVS tree to HEAD today (2009-02-03, around noon PST),
> compiled it, and started using it.  My previous sync had been around
> 2008-12-01.  During that interval, the performance of inserting long
> lines into the *compilation* buffer has dropped by an order of
> magnitude.

I've only recently started taking a look at compile.el and haven't had
a chance to investigate this problem, but I just tried:

  M-x compile RET echo C-u 6400 x RET

and it finished instantly.  Maybe this is because the problem was fixed
a while ago.  But I also just installed a change which should
significantly help such cases by only processing lines when they're
complete, which avoids an N^2 behavior.


        Stefan

Re: Performance regression in CVS HEAD's *compilation* buffer

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I updated my CVS tree to HEAD today (2009-02-03, around noon PST),
>> compiled it, and started using it.  My previous sync had been around
>> 2008-12-01.  During that interval, the performance of inserting long
>> lines into the *compilation* buffer has dropped by an order of
>> magnitude.
>
> I've only recently started taking a look at compile.el and haven't had
> a chance to investigate this problem, but I just tried:
>
>   M-x compile RET echo C-u 6400 x RET
>
> and it finished instantly.

Because that would arrive batched.  Try

M-x compile RET echo C-u 6400 x | dd obs=1 RET

-- 
David Kastrup

Re: Performance regression in CVS HEAD's *compilation* buffer

[Stefan Monnier]

>>> I updated my CVS tree to HEAD today (2009-02-03, around noon PST),
>>> compiled it, and started using it.  My previous sync had been around
>>> 2008-12-01.  During that interval, the performance of inserting long
>>> lines into the *compilation* buffer has dropped by an order of
>>> magnitude.
>> I've only recently started taking a look at compile.el and haven't had
>> a chance to investigate this problem, but I just tried:
>> M-x compile RET echo C-u 6400 x RET
>> and it finished instantly.
> Because that would arrive batched.  Try
> M-x compile RET echo C-u 6400 x | dd obs=1 RET

Good point.  But I just tried it and it seems to still be "instantaneous".


        Stefan