Emacs HEAD regressions

Emacs HEAD regressions

[Angelo Graziosi]

It seems that recently someone [1,2,3] is flagging different problems
with a common base: performance.

I have tried to reproduce the test case in [3]. In my case, surely I
have misinterpreted something because compiling exits abnormally with
code 127 BUT...

with Emacs CVS <= 20090129 15:40 it takes 2 seconds
with current HEAD it takes 11 seconds to exit

For the record: changing ONLY the new 'emacs' executable with the older,
works just fine.

Cheers,
    Angelo.

---
[1] http://lists.gnu.org/archive/html/emacs-devel/2009-02/msg00162.html

[2] http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-02/msg00108.html

[3] http://lists.gnu.org/archive/html/emacs-devel/2009-02/msg00226.html

Re: Emacs HEAD regressions

[sand]

Angelo Graziosi writes:
> It seems that recently someone [1,2,3] is flagging different problems
> with a common base: performance.
> 
> I have tried to reproduce the test case in [3]. In my case, surely I
> have misinterpreted something because compiling exits abnormally with
> code 127 BUT...

Anything that can generate 6kB lines in your complation buffer should
do.  Try calling a shell script that writes the long line.  For me, it
was a long compilation line from "make".

> with Emacs CVS <= 20090129 15:40 it takes 2 seconds
> with current HEAD it takes 11 seconds to exit
> 
> For the record: changing ONLY the new 'emacs' executable with the older,
> works just fine.

I was also able to narrow it down to around that date.

  cvs up -D 2009-01-29

works fine with my test case,

  cvs up -D 2009-01-30

is slow with my test case.  The datestamps here are from a machine in
the US/Pacific time zone.

Derek

Re: Emacs HEAD regressions (another test case)

[Angelo Graziosi]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

sand@blarg.net ha scritto:
> 
> Anything that can generate 6kB lines in your complation buffer should
> do.  Try calling a shell script that writes the long line.  For me, it
> was a long compilation line from "make".

Indeed! The attached script 'prints' 6x1024 'x' characters, and on
GNU/LINUX KUBUNTU 8.04.02 it takes:

4 seconds with Emacs CVS LESS THAN OR EQUAL TO (<=) 20090129 15:30

2:15 minutes, i.e. 60x2+15=135 seconds with Emacs GREATER THAN OR EQUAL
TO (>=) 20090129 15:40!

To reproduce:

$ emacs -Q &

M-x compile
C-a C-k
./test_script-6KB.sh

> 
> I was also able to narrow it down to around that date.
> 
>   cvs up -D 2009-01-29
> 
> works fine with my test case,
> 
>   cvs up -D 2009-01-30

see above...

Cheers,
    Angelo.

---
References:

http://lists.gnu.org/archive/html/emacs-devel/2009-02/msg00162.html


[-- Attachment #2: test_script-6KB.sh.bz2 --]
[-- Type: application/octet-stream, Size: 74 bytes --]

Re: Emacs HEAD regressions (another test case)

[sand]

Angelo Graziosi writes:
> sand@blarg.net ha scritto:
> > 
> > Anything that can generate 6kB lines in your complation buffer should
> > do.  Try calling a shell script that writes the long line.  For me, it
> > was a long compilation line from "make".
> 
> Indeed! The attached script 'prints' 6x1024 'x' characters, and on
> GNU/LINUX KUBUNTU 8.04.02 it takes:
> 
> 4 seconds with Emacs CVS LESS THAN OR EQUAL TO (<=) 20090129 15:30
> 
> 2:15 minutes, i.e. 60x2+15=135 seconds with Emacs GREATER THAN OR EQUAL
> TO (>=) 20090129 15:40!
> 
> To reproduce:
> 
> $ emacs -Q &
> 
> M-x compile
> C-a C-k
> ./test_script-6KB.sh
> 

I can repro the success and failure cases on those two times.  Note
that people need to set their timezone to CET for those timestamps to
be accurate:

  env TZ=CET cvs diff -D '2009-01-29 15:30' -D '2009-01-29 15:40'

That diff contains changes for pending signals.

+2009-01-29  Chong Yidong  <cyd@stupidchicken.com>
+
+       * keyboard.c (pending_signals): New var.
+       (poll_for_input, input_available_signal, init_keyboard): Set it.
+       (process_pending_signals): New function.
+
+       * lisp.h (QUIT): Check pending_signals instead of
+       interrupt_input_pending.  Use process_pending_signals.
+
+       * atimer.c (run_timers, alarm_signal_handler): Update
+       pending_signals.
+
+       * process.c (wait_reading_process_output): Use
+       process_pending_signals.
+
+       * sysdep.c (emacs_write): Use process_pending_signals.
+
+       * xterm.c (XTread_socket): Update pending_signals.
+
+       * w32term.c (w32_read_socket): Update pending_signals.
+
+       * w32inevt.c (w32_console_read_socket): Update pending_signals.
+

Derek

Re: Emacs HEAD regressions (another test case)

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 05 Feb 2009 11:08:44 +0100, Angelo Graziosi <angelo.graziosi@alice.it> said:

>> Anything that can generate 6kB lines in your complation buffer should
>> do.  Try calling a shell script that writes the long line.  For me, it
>> was a long compilation line from "make".

> Indeed! The attached script 'prints' 6x1024 'x' characters, and on
> GNU/LINUX KUBUNTU 8.04.02 it takes:

> 4 seconds with Emacs CVS LESS THAN OR EQUAL TO (<=) 20090129 15:30

> 2:15 minutes, i.e. 60x2+15=135 seconds with Emacs GREATER THAN OR EQUAL
> TO (>=) 20090129 15:40!

Could you try the patch below to see if it affects the performance?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/atimer.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/atimer.c,v
retrieving revision 1.31
diff -c -p -r1.31 atimer.c
*** src/atimer.c	30 Jan 2009 13:06:09 -0000	1.31
--- src/atimer.c	6 Feb 2009 10:59:24 -0000
*************** run_timers ()
*** 384,389 ****
--- 384,391 ----
        EMACS_GET_TIME (now);
      }
  
+   if (atimers == NULL)
+     pending_atimers = 0;
  #ifdef SYNC_INPUT
    if (pending_atimers)
      pending_signals = 1;

Re: Emacs HEAD regressions (another test case)

[Angelo Graziosi]

YAMAMOTO Mitsuharu ha scritto:

> 
> Could you try the patch below to see if it affects the performance?

With the patch, Emacs HEAD works just fine!

Thanks,
    Angelo.


> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> Index: src/atimer.c
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/src/atimer.c,v
> retrieving revision 1.31
> diff -c -p -r1.31 atimer.c
> *** src/atimer.c	30 Jan 2009 13:06:09 -0000	1.31
> --- src/atimer.c	6 Feb 2009 10:59:24 -0000
> *************** run_timers ()
> *** 384,389 ****
> --- 384,391 ----
>         EMACS_GET_TIME (now);
>       }
>   
> +   if (atimers == NULL)
> +     pending_atimers = 0;
>   #ifdef SYNC_INPUT
>     if (pending_atimers)
>       pending_signals = 1;

Re: Emacs HEAD regressions (another test case)

[sand]

Angelo Graziosi writes:
> With the patch, Emacs HEAD works just fine!

That fixes it for me as well.

Thanks,

Derek

Re: Emacs HEAD regressions (another test case)

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Could you try the patch below to see if it affects the performance?

Thanks for finding the fix.  I've checked it in.

Re: Emacs HEAD regressions (another test case)

[Bruce Stephens]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

[...]

> Indeed! The attached script 'prints' 6x1024 'x' characters, and on
> GNU/LINUX KUBUNTU 8.04.02 it takes:
>
> 4 seconds with Emacs CVS LESS THAN OR EQUAL TO (<=) 20090129 15:30
>
> 2:15 minutes, i.e. 60x2+15=135 seconds with Emacs GREATER THAN OR EQUAL
> TO (>=) 20090129 15:40!

I think it's the pending_signals changes, dated (in the git
repository) 2009-01-29 14:32:21 to 2009-01-29 14:35:25.  If I revert
those, then HEAD gives the ~4 seconds behaviour.

(I guess the apparent time difference is because you're in a +0100
timezone.)

[...]