Is it just me, or did 21.3.50 get a whole lot slower?

Is it just me, or did 21.3.50 get a whole lot slower?

[John Wiegley]

I haven't been building from CVS sources in a half a year, so I'm
sorry I don't have a more recent comparison.  I've been using Debian
21.2 package for active development these past months.

Anyway, I built 21.3.50 the other day, and ran it on my 300 MHz
Pentium-MMX laptop (which has 96 MB of memory).  I had just been
coding for three hours using 21.2, so I had a good sense of how fast
it ought to have been.

First I noticed the nifty new color schemes, and fading modelines.
However, I also saw that it was WAY WAY slower than 21.2.  'M-x' took
0.2 seconds to show a prompt; there was a lag on inserting characters;
RET at the end of a line waiting up to 2 full seconds at time.  I
turned on garbage collection messages, but Lisp memory usage didn't
seem abnormal.

What I did notice is lots and lots of screen flicker.  It seems that
refreshes were happening very often (maybe once every few seconds),
which is very different from 21.2, where flicker just never happens.

Has anyone else seen this, or might this just be an oddity of my
system?  I will try to track this down more.  I compiled with "-g
-O2", without Xaw3d or scrollbars or graphics support.  I am using
Mule.

John

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[D. Goel]

A somewhat (un)related comparison:
 
  On a SunOS, i haven't noticed any noticeable difference among the
  speeds of 21.1 and 21.2.90.

  (even more unrelated: 

    emacs (both 21.1 and 21.2.90, and others) does get really slow
    when (length load-history) touches 290--300ish.. which frustrates me,
    but i guess that can't be helped.. (?)..)

DG				   <http://www.glue.umd.edu/~deego/>
-- 

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

	emacs (both 21.1 and 21.2.90, and others) does get really slow
	when (length load-history) touches 290--300ish.. which frustrates me,
	but i guess that can't be helped.. (?)..)

Which operations get slow?  Who knows whether this can be helped,
until we investigate it.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[D. Goel]

Richard Stallman <rms@gnu.org> writes:

> 	emacs (both 21.1 and 21.2.90, and others) does get really slow
> 	when (length load-history) touches 290--300ish.. which frustrates me,
> 	but i guess that can't be helped.. (?)..)
> 
> Which operations get slow?  Who knows whether this can be helped,
> until we investigate it.


I shall look into profiling etc. and get back to this list with
precise statistics re: speed vs. (lengh load-history).



DG				   <http://www.glue.umd.edu/~deego/>
-- 

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

    > 	emacs (both 21.1 and 21.2.90, and others) does get really slow
    > 	when (length load-history) touches 290--300ish.. which frustrates me,
    > 	but i guess that can't be helped.. (?)..)
    > 
    > Which operations get slow?  Who knows whether this can be helped,
    > until we investigate it.


    I shall look into profiling etc. and get back to this list with
    precise statistics re: speed vs. (lengh load-history).

I see I did not choose my words clearly.  I am sorry.

The first question is, which *user-level* operations get slow in this
situation?  That you should know from simple observation.

Looking at the code in one of those user-level operations might lead
you pretty directly to the primitive that gets slow.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[D. Goel]

RMS 

> The first question is, which *user-level* operations get slow in this
> situation?  That you should know from simple observation.


it seems that when things get slow, everything gets slow.. it seems to
take emacs a minute to even recognize a C-n ... 

> 
> Looking at the code in one of those user-level operations might lead
> you pretty directly to the primitive that gets slow.

i shall look into this .. and next time i get back on this issue, will
get back with somethign concrete and more details.



however, from more observatinos i have made in the last 3 days, i am
still unsure that it is emacs (rather than my connection) that gets
slow..  so the next time i get back, it shall be something concrete.

Thanks for caring about this issue..  i had expected more of a
response like: "Well, tough luck, if you intern a million symbols,
what else do you expect?  Go start a new fresh emacs!"  :)



DG				   
-- 

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Eli Zaretskii]

On 18 Jun 2002, D. Goel wrote:

> it seems that when things get slow, everything gets slow.. it seems to
> take emacs a minute to even recognize a C-n ... 

Is it really a minute, or just ``too long to wait''?

If it really takes a minute, I'd first try to see if your system runs out 
of physical memory and starts paging.  Do you see amy significant disk 
activity during this time?

Also, please set garbage-collection-messages non-nil and see if GC is 
happening during those periods of slow-down.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[John Wiegley]

>>>>> On Tue Jun 18, Eli writes:

> On 18 Jun 2002, D. Goel wrote:
>> it seems that when things get slow, everything gets slow.. it seems
>> to take emacs a minute to even recognize a C-n ...

> Is it really a minute, or just ``too long to wait''?

> If it really takes a minute, I'd first try to see if your system
> runs out of physical memory and starts paging.  Do you see amy
> significant disk activity during this time?

You know, I've noticed further than 21.3.50 isn't super slow at the
beginning, but only after I've been using Emacs for about a minute.
It is still on my list to track down what's causing it to slow down,
but at least I know the slowdown is not universal, but related to
something I'm doing or activating.

John

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[D. Goel]

Eli


Eli Zaretskii <eliz@is.elta.co.il> writes:
> > it seems that when things get slow, everything gets slow.. it seems to
> > take emacs a minute to even recognize a C-n ... 
> 
> Is it really a minute, or just ``too long to wait''?

I think the latter.   Will try to measure it the next time it occurs,
and get back. 

While i was writing this email, some more 'reflection' happened, and I
now suspect that this might rather be a problem due to glue.umd.edu
shrinking the CPU cycles it provides to emacs, and may not be an emacs
problem (see below).

> 
> If it really takes a minute, I'd first try to see if your system
> runs out of physical memory and starts paging.  Do you see amy
> significant disk activity during this time?

oh, this always happens to, say, foo.glue.umd.edu----a remote machine
i log into, so can't really find out disk activity :( 

> Also, please set garbage-collection-messages non-nil and see if GC
> is happening during those periods of slow-down.
  

 Thanks Eli.  Always been non-nil.  And the 'freezes' were not GC.


====================================================
(What had initially made me suspect emacs was:

  I will be logged into foo.glue.umd.edu from one putty from a PC and
  using emacs.

  And i will be logged into the same foo.glue.umd.edu from another
  putty from the same windoze PC and using tcsh.

 The latter continues to be responsive, while the former sometimes
 'froze' up for ages, (that's i assumed this is an emacs problem)...
 This always seemed to happen after the emacs was 'big', and the
 terminal would be idle.  So, i would go to the emacs and type
 something, trying to 'activate' it.. but it will remaiin sluggish for
 a long time---say 5--10 minutes..  (by then i would have killed
 it.. :-)

As mentioned above, i think this could be due to glue.umd.edu
shrinking Emacs' CPU time with time----emacs would have been an
application 'idle for half the time' and a 'memory hog' the remaining
time, and running for 10 hours---perhaps all of these things
contribute to CPU-cycle- shrinking on a 'shared system'...

I think i have never observed the slow-emacs phenomenon on any of the
local SunOS's in my company.. so less sure than ever that this is an
emacs problem. 

)



Thanks to all of you for caring. 

DG				   
-- 

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

    it seems that when things get slow, everything gets slow.. it seems to
    take emacs a minute to even recognize a C-n ... 

How strange.  Well, it should be easy to investigate this.  Run Emacs
under GDB, and when it gets slow, stop it with C-z a few times and run
`backtrace' and `xbacktrace' each time.  After a few times, you will
see where Emacs is spending its time.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Kai Großjohann]

There is no (Kai-)perceptible difference between 21.1, 21.2, 21.2.90
and the current CVS head.  Hm.

Does the variable system-configuration-options show anything
significant between the two versions?

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

    First I noticed the nifty new color schemes, and fading modelines.
    However, I also saw that it was WAY WAY slower than 21.2.  'M-x' took
    0.2 seconds to show a prompt; there was a lag on inserting characters;
    RET at the end of a line waiting up to 2 full seconds at time.

Chances are this is due to some rather simple change, and we could
easily fix it if only we knew what.  If it does not happen to most
people, maybe it is due to a change in some package or feature that
you use.  Could you see if it is equally slow if you do `emacs -q'?

Is there any chance you can stop Emacs during those 2 seconds?  If you
can start Emacs under GDB, then during that time if you move the mouse
into the window where GDB is running and type C-c, it might stop
Emacs in time to get a backtrace.  If you do that a few times,
it might show you where the time is being spent.

    What I did notice is lots and lots of screen flicker.  It seems that
    refreshes were happening very often (maybe once every few seconds),
    which is very different from 21.2, where flicker just never happens.

You can set breakpoints in various parts of redisplay, such as
try_window and try_window_id, and set commands on them to continue
automatically.  That way, they will print out in the GDB window but
won't actually stop Emacs.  By comparing the slow version and a faster
version, you might see a difference in pattern which would tell us
something.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[John Wiegley]

An update: I haven't yet run under GDB, but today I finally updated
to the newest Emacs 21.3.50 from CVS, and tried running again on my
laptop (P300, 96 Mb RAM, slow hard drive).

After pressing "reply" to compose this e-mail, I went to the first
line of the message and typed "C-n" four times.  I had my co-worker
time the pause on his stopwatch.  It took 5 wall-clock seconds for
the cursor to move.

Yes, I have a lot of packages loaded, but realize that on the same
machine, 21.2 does not pause at all.

My time is limited this year to work on the problem, but maybe
someone who knows the C sources better would be willing to login to
IRC and help me track things down?  My typing has been a full
sentence behind me while writing this letter.

John

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

    After pressing "reply" to compose this e-mail, I went to the first
    line of the message and typed "C-n" four times.  I had my co-worker
    time the pause on his stopwatch.  It took 5 wall-clock seconds for
    the cursor to move.

Can you use GDB to stop it while this happens?
If you do that even 4 times you will probably see where it
is spending most of that time.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[John Wiegley]

>>>>> On Mon Dec 30, Richard writes:

>     After pressing "reply" to compose this e-mail, I went to the
> first line of the message and typed "C-n" four times.  I had my
> co-worker time the pause on his stopwatch.  It took 5 wall-clock
> seconds for the cursor to move.

> Can you use GDB to stop it while this happens?  If you do that even
> 4 times you will probably see where it is spending most of that
> time.

This issue is now closed.  I discovered that the implementation of
"wide-column.el" was the culprit.  It was abusing the
post-command-hook in a way that worked in 21.2, but not in 21.3.  I
have referred the problem to the author.

John

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

    This issue is now closed.  I discovered that the implementation of
    "wide-column.el" was the culprit.  It was abusing the
    post-command-hook in a way that worked in 21.2, but not in 21.3.  I
    have referred the problem to the author.

Can you tell me what the problem is?  Maybe I should fix what broke.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[John Wiegley]

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

>>>>> On Thu Jan  2, Richard writes:

>> This issue is now closed.  I discovered that the implementation of
>> "wide-column.el" was the culprit.  It was abusing the
>> post-command-hook in a way that worked in 21.2, but not in 21.3.
>> I have referred the problem to the author.

> Can you tell me what the problem is?  Maybe I should fix what
> broke.

I did not take the time to track it down, nor can I just yet.  I
would recommend talking with the author, as likely he will be
interested in fixing it to be compatible with 21.3.  His e-mail is:

  Phillip Lord <p.lord@russet.org.uk>

To reproduce, just load the module in 21.3 and start using it during
your regular workday.  The slow-down should become apparent.


[-- Attachment #2: wide-column.el --]
[-- Type: application/emacs-lisp, Size: 14092 bytes --]

[-- Attachment #3: Type: text/plain, Size: 6 bytes --]


John

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

    >> This issue is now closed.  I discovered that the implementation of
    >> "wide-column.el" was the culprit.  It was abusing the
    >> post-command-hook in a way that worked in 21.2, but not in 21.3.
    >> I have referred the problem to the author.

    > Can you tell me what the problem is?  Maybe I should fix what
    > broke.

    I did not take the time to track it down, nor can I just yet.  I
    would recommend talking with the author,

We are having a misunderstanding.  I am not talking about changing
wide-column.el.

You say that wide-column.el is doing something with post-command-hook
that worked in 21.2 but not in 21.3.  Can you show me what it is
doing?  Maybe I should change 21.3 so that that usage works once more.

I assume that in order to form an opinion of that usage you must first
have seen what the usage consists of.  So I figure you can tell me this
quickly.  Is that not so?

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[John Wiegley]

>>>>> On Fri Jan  3, Richard writes:

> You say that wide-column.el is doing something with
> post-command-hook that worked in 21.2 but not in 21.3.  Can you
> show me what it is doing?  Maybe I should change 21.3 so that that
> usage works once more.

Ah, I understand.  Perhaps then I can help you track this difference
down.

> I assume that in order to form an opinion of that usage you must
> first have seen what the usage consists of.  So I figure you can
> tell me this quickly.  Is that not so?

It is not so.  I merely noticed the slow down, and then
systematically disabled module after module until the problem
disappeared.  Then I re-enabled and dis-enabled, to confirm that the
inclusion of wide-column.el would manifest the problem.  Once I saw
the entry on post-command-hook, I made an assumption, because
clearing post-command-hook also causes the problem to go away.

I will have to allocate time next week to isolating this problem for
you.

John

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Kim F. Storm]

John Wiegley <johnw@gnu.org> writes:

> I will have to allocate time next week to isolating this problem for
> you.
> 

wide-column.el does various things with the current buffer and the
cursor color in the post-command-hook; I don't know if there are
changes from 21.2 to 21.3 related to the cursor or current buffer that
may explain the slow-down.

Maybe you can selectively comment-out various parts of the function
added to the post-command-hook to see what may be responsible for the
slow-down.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

    I will have to allocate time next week to isolating this problem for
    you.

Thanks.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Phillip Lord]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

  >>> This issue is now closed.  I discovered that the implementation
  >>> of "wide-column.el" was the culprit.  It was abusing the
  >>> post-command-hook in a way that worked in 21.2, but not in 21.3.
  >>> I have referred the problem to the author.

  >> Can you tell me what the problem is?  Maybe I should fix what
  >> broke.

  Richard>     I did not take the time to track it down, nor can I
  Richard>     just yet.  I would recommend talking with the author,

  Richard> We are having a misunderstanding.  I am not talking about
  Richard> changing wide-column.el.

  Richard> You say that wide-column.el is doing something with
  Richard> post-command-hook that worked in 21.2 but not in 21.3.  Can
  Richard> you show me what it is doing?  Maybe I should change 21.3
  Richard> so that that usage works once more.

  Richard> I assume that in order to form an opinion of that usage you
  Richard> must first have seen what the usage consists of.  So I
  Richard> figure you can tell me this quickly.  Is that not so?



I'm sorry for the delay in replying to this thread, but I've been away
since Christmas. 

All wide-column is supposed to do, by default, is switch the cursor
colour when the cursor is based 80 columns. In addition it calls some
functions when the buffer is changed, to fake buffer local cursor
colour.

I haven't tried 21.3 yet. Is this a CVS version rather than pretest?
Or did I miss an announcement in the flurry of christmas spam?

Phil

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[John Wiegley]

>>>>> On Tue Jan 14, Phillip writes:

> I haven't tried 21.3 yet. Is this a CVS version rather than
> pretest?  Or did I miss an announcement in the flurry of christmas
> spam?

I have only been looking at the CVS version.

John

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

He's talking about the version in CVS.  I am hoping to find out what
changed in Emacs that caused wide-column.el not to work, so I cna fix it.

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Phillip Lord]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

  Richard> He's talking about the version in CVS.  I am hoping to find
  Richard> out what changed in Emacs that caused wide-column.el not to
  Richard> work, so I cna fix it.


Okay. Please let me know if there are any changes that I need to
incorporate into wide-column.el. I'm sorry that I can't offer to help
debug this, but I'm too snowed under with work at the moment. 

Phil

Re: Is it just me, or did 21.3.50 get a whole lot slower?

[Richard Stallman]

    Okay. Please let me know if there are any changes that I need to
    incorporate into wide-column.el. I'm sorry that I can't offer to help
    debug this, but I'm too snowed under with work at the moment. 

I want to fix the underlying Emacs mechanism so that you won't have to
change anything.  To do that, I need help identifying what is broken in
the underlying mechanism.

Looks like I found the slowdown

[John Wiegley]

It seems that the "wide-column.el" adds a function to
`post-command-hook' which causes excessive refreshing to occur
(after every keystroke).  Once I remove that module, I find that
21.3.50 seems a bit faster than 21.2.

John

Re: Looks like I found the slowdown

[Richard Stallman]

    It seems that the "wide-column.el" adds a function to
    `post-command-hook' which causes excessive refreshing to occur
    (after every keystroke).

It looks like wide-column.el is not part of Emacs,
but maybe its author could improve this aspect of it.