Slow repainting, sluggish feeling emacs

Slow repainting, sluggish feeling emacs

[David]

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

I recently re-built emacs 23 from cvs and there's a noticeable delay in many
repainting operations. Typing is sluggish and redrawing a buffer when
switching to it is noticeably slow.

So I tried to measure the difference.  I started two versions of emacs with
--no-init, loaded nothing, and immediately ran elp-instrument-function on
"ibuffer".  Here are the results:

emacs(GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-02-20 on
U0103223-XPA)
Function Name Call Count Elapsed Time Average Time
ibuffer        1           0.0           0.0


GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-05-12 on U0103223-XPA
Function Name Call Count Elapsed Time Average Time
ibuffer        1           0.032         0.032

I ran elp-instrument-function again and got:
ibuffer        1           0.047         0.047

The time difference is very small, but with a loaded up emacs config the
time becomes very noticeable.
I built emacs on windows-xp using cygwin(-mno-cygwin however), ming32-make.
Both versions of the build where 'configured' the same:

Here's the 'report-emacs-bug' important stuff:


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-05-12 on U0103223-XPA
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -I../../include -msse3
-O3'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x M-p i <backspace> e l p 0 <backspace> - i n s t
r <tab> f u n <tab> <return> i b u f f e r <return>
M-x l o a d - l i <tab> <return> i b u f f e r <return>
M-x M-p M-p <return> M-p <return> M-x i b u f f e r
<return> q C-x b C-g C-x C-b <down> <down> <down> <down>
<down> <down> q C-x 1 M-x i b u f f e r - <M-backspace>
e l p - r e s u l <tab> <return> C-SPC <down> M-w q
M-x r e p o r <tab> <return>

Recent messages:
goto-history-element: Beginning of history; no preceding item
elp-instrument-function: ELP cannot profile autoloaded function: ibuffer
Loading ibuffer...done
Updating buffer list...
Formats have changed, recompiling...done
Mark set
Updating buffer list...done
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
Quit
Mark set

[-- Attachment #2: Type: text/html, Size: 3779 bytes --]

Re: Slow repainting, sluggish feeling emacs

[dhruva]

Hello,

On 5/13/08, David <david.boon@gmail.com> wrote:
> I recently re-built emacs 23 from cvs and there's a noticeable delay in many
> repainting operations. Typing is sluggish and redrawing a buffer when
> switching to it is noticeably slow.

I am noticing a similar behavior from the past 4~5 days. Is it related
to some change in "w32-get-true-file-attributes" modifications, well I
am taking a real wild guess based on ChangeLog history and my memory
from when I started seeing this slow down. I still do not have a MSVC
build and hence debugging is a big problem. I tried debugging the MSVC
issue, some GC related issue and have no clue about it!

-dhruva

-- 
Contents reflect my personal views only!

Re: Slow repainting, sluggish feeling emacs

[dhruva]

My expereince is more concerned with visiting files. I tried setting
w32-get-true-file-attributes to nil. It appears to be faster than
before but I need to test it further.

-dhruva

On 5/13/08, dhruva <dhruvakm@gmail.com> wrote:
> Hello,
>
>
>  On 5/13/08, David <david.boon@gmail.com> wrote:
>  > I recently re-built emacs 23 from cvs and there's a noticeable delay in many
>  > repainting operations. Typing is sluggish and redrawing a buffer when
>  > switching to it is noticeably slow.
>
>
> I am noticing a similar behavior from the past 4~5 days. Is it related
>  to some change in "w32-get-true-file-attributes" modifications, well I
>  am taking a real wild guess based on ChangeLog history and my memory
>  from when I started seeing this slow down. I still do not have a MSVC
>  build and hence debugging is a big problem. I tried debugging the MSVC
>  issue, some GC related issue and have no clue about it!
>
>  -dhruva
>
>
>  --
>  Contents reflect my personal views only!
>


-- 
Contents reflect my personal views only!

Re: Slow repainting, sluggish feeling emacs

[Eric Lilja]

David wrote:
> I recently re-built emacs 23 from cvs and there's a noticeable delay in 
> many repainting operations. Typing is sluggish and redrawing a buffer 
> when switching to it is noticeably slow.
[snip]

Hi David, have you tried launching emacs with --disable-font-backend to 
see if it feels more snappy?
Oh, just a tiny disclaimer: I haven't built the emacs trunk since some 
time in febraury so I don't know if that switch is needed or even if it 
exists anymore, but it did indeed help me with my performace problems I 
was having a few months ago (also on Windows).

The past few months I've been working on my new job and here we use 
eclipse and oxygenxml for all our editing needs (xml-files, xml-schemas 
and java) and I haven't gotten around to keeping up with the trunk on my 
personal computers.

- Eric

Re: Slow repainting, sluggish feeling emacs

[Eli Zaretskii]

> Date: Tue, 13 May 2008 10:40:23 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
> 
> My expereince is more concerned with visiting files. I tried setting
> w32-get-true-file-attributes to nil. It appears to be faster than
> before but I need to test it further.

The OP reported slowdown with redisplay and ibuffer, which I think
cannot have anything to do with the changes in w32 subroutines called
by file-attributes.

As for what you see, I announced here that the changes I made in the
emulation of `stat' in w32.c could very well make Emacs slower in
accessing many files, like in Dired.  I intend to work on speeding
that up, but in the meantime, if the slowdown annoys you, I advised to
set w32-get-true-file-attributes to nil.  If even setting it to nil
doesn't help, then the slowdown has nothing to do with my changes to
`stat' (whose purpose was to report true owner of each file and its
primary group), because a nil value causes `stat' to shortcut the code
I added.

Processed: Slow repainting, sluggish feeling emacs

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> reassign 233 emacs,w32
bug#233: Slow repainting, sluggish feeling emacs
Warning: Unknown package 'w32'
bug reassigned from package `emacs' to `emacs,w32'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#233: marked as done (Slow repainting, sluggish feeling emacs)

[Emacs bug Tracking System]

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


Your message dated Wed, 30 Jul 2008 23:09:06 +0100
with message-id <4890E682.6090108@gnu.org>
and subject line Slow repainting, sluggish feeling emacs
has caused the Emacs bug report #233,
regarding Slow repainting, sluggish feeling emacs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
233: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=233
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 11686 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 2730 bytes --]

I recently re-built emacs 23 from cvs and there's a noticeable delay in many
repainting operations. Typing is sluggish and redrawing a buffer when
switching to it is noticeably slow.

So I tried to measure the difference.  I started two versions of emacs with
--no-init, loaded nothing, and immediately ran elp-instrument-function on
"ibuffer".  Here are the results:

emacs(GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-02-20 on
U0103223-XPA)
Function Name Call Count Elapsed Time Average Time
ibuffer        1           0.0           0.0


GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-05-12 on U0103223-XPA
Function Name Call Count Elapsed Time Average Time
ibuffer        1           0.032         0.032

I ran elp-instrument-function again and got:
ibuffer        1           0.047         0.047

The time difference is very small, but with a loaded up emacs config the
time becomes very noticeable.
I built emacs on windows-xp using cygwin(-mno-cygwin however), ming32-make.
Both versions of the build where 'configured' the same:

Here's the 'report-emacs-bug' important stuff:


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-05-12 on U0103223-XPA
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -I../../include -msse3
-O3'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x M-p i <backspace> e l p 0 <backspace> - i n s t
r <tab> f u n <tab> <return> i b u f f e r <return>
M-x l o a d - l i <tab> <return> i b u f f e r <return>
M-x M-p M-p <return> M-p <return> M-x i b u f f e r
<return> q C-x b C-g C-x C-b <down> <down> <down> <down>
<down> <down> q C-x 1 M-x i b u f f e r - <M-backspace>
e l p - r e s u l <tab> <return> C-SPC <down> M-w q
M-x r e p o r <tab> <return>

Recent messages:
goto-history-element: Beginning of history; no preceding item
elp-instrument-function: ELP cannot profile autoloaded function: ibuffer
Loading ibuffer...done
Updating buffer list...
Formats have changed, recompiling...done
Mark set
Updating buffer list...done
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
Quit
Mark set

[-- Attachment #2.1.2: Type: text/html, Size: 4049 bytes --]

[-- Attachment #3: Type: message/rfc822, Size: 1894 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: 233-done@emacsbugs.donarmstrong.com
Subject: Slow repainting, sluggish feeling emacs
Date: Wed, 30 Jul 2008 23:09:06 +0100
Message-ID: <4890E682.6090108@gnu.org>

reassign 233 emacs,w32
thanks

It seems that the performance issues are resolved by using uniscribe's
built in caching for glyph encoding, and avoiding explicit encoding in
the gdi backend.

bug#233: closed by Jason Rumney <jasonr@gnu.org> (Slow repainting, sluggish feeling emacs)

[David]

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

Hi Jason , I've built latest and and things are better, but noticeably
sluggish still.  Especially on larger files, but not significantly large.
For example, I have a file that is 218 lines long, if I hold down C-n and
count, I can count to 10 before the cursor moves anywhere, and it doesn't
actually do any moving until I release the keys.

If I do the same 'test' with an older emacs, built from CVS on 02-20-2008, I
get immediate screen scrolling and cursor movement.

 -David

On Wed, Jul 30, 2008 at 6:15 PM, Emacs bug Tracking System <
don@donarmstrong.com> wrote:

>
> This is an automatic notification regarding your bug report
> which was filed against the emacs,w32 package:
>
> #233: Slow repainting, sluggish feeling emacs
>
> It has been closed by Jason Rumney <jasonr@gnu.org>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Jason Rumney <
> jasonr@gnu.org> by
> replying to this email.
>
>
> --
> 233: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=233
> Emacs Bug Tracking System
> Contact don@donarmstrong.com with problems
>
>
> ---------- Forwarded message ----------
> From: Jason Rumney <jasonr@gnu.org>
> To: 233-done@emacsbugs.donarmstrong.com
> Date: Wed, 30 Jul 2008 23:09:06 +0100
> Subject: Slow repainting, sluggish feeling emacs
> reassign 233 emacs,w32
> thanks
>
> It seems that the performance issues are resolved by using uniscribe's
> built in caching for glyph encoding, and avoiding explicit encoding in
> the gdi backend.
>
>
>
> ---------- Forwarded message ----------
> From: David <david.boon@gmail.com>
> To: emacs-devel@gnu.org
> Date: Mon, 12 May 2008 21:10:39 -0400
> Subject: Slow repainting, sluggish feeling emacs
> I recently re-built emacs 23 from cvs and there's a noticeable delay in
> many repainting operations. Typing is sluggish and redrawing a buffer when
> switching to it is noticeably slow.
>
> So I tried to measure the difference.  I started two versions of emacs with
> --no-init, loaded nothing, and immediately ran elp-instrument-function on
> "ibuffer".  Here are the results:
>
> emacs(GNU Emacs *MailScanner warning: numerical links are often malicious:
> * 23.0.60.1 <http://23.0.60.1> (i386-mingw-nt5.1.2600) of 2008-02-20 on
> U0103223-XPA)
> Function Name Call Count Elapsed Time Average Time
> ibuffer        1           0.0           0.0
>
>
> GNU Emacs *MailScanner warning: numerical links are often malicious:*23.0.60.1<http://23.0.60.1>(i386-mingw-nt5.1.2600) of 2008-05-12 on U0103223-XPA
> Function Name Call Count Elapsed Time Average Time
> ibuffer        1           0.032         0.032
>
> I ran elp-instrument-function again and got:
> ibuffer        1           0.047         0.047
>
> The time difference is very small, but with a loaded up emacs config the
> time becomes very noticeable.
> I built emacs on windows-xp using cygwin(-mno-cygwin however),
> ming32-make.  Both versions of the build where 'configured' the same:
>
> Here's the 'report-emacs-bug' important stuff:
>
>
> In GNU Emacs *MailScanner warning: numerical links are often malicious:*23.0.60.1<http://23.0.60.1>(i386-mingw-nt5.1.2600)
>  of 2008-05-12 on U0103223-XPA
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --cflags -I../../include
> -msse3 -O3'
>
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: ENU
>   value of $XMODIFIERS: nil
>   locale-coding-system: cp1252
>   default-enable-multibyte-characters: t
>
> Major mode: Fundamental
>
> Minor modes in effect:
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   blink-cursor-mode: t
>   global-auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
>
> Recent input:
> M-x M-p i <backspace> e l p 0 <backspace> - i n s t
> r <tab> f u n <tab> <return> i b u f f e r <return>
> M-x l o a d - l i <tab> <return> i b u f f e r <return>
> M-x M-p M-p <return> M-p <return> M-x i b u f f e r
> <return> q C-x b C-g C-x C-b <down> <down> <down> <down>
> <down> <down> q C-x 1 M-x i b u f f e r - <M-backspace>
> e l p - r e s u l <tab> <return> C-SPC <down> M-w q
> M-x r e p o r <tab> <return>
>
> Recent messages:
> goto-history-element: Beginning of history; no preceding item
> elp-instrument-function: ELP cannot profile autoloaded function: ibuffer
> Loading ibuffer...done
> Updating buffer list...
> Formats have changed, recompiling...done
> Mark set
> Updating buffer list...done
> Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
> Quit
> Mark set
>
>
>

[-- Attachment #2: Type: text/html, Size: 6974 bytes --]

bug#233: closed by Jason Rumney <jasonr@gnu.org> (Slow repainting, sluggish feeling emacs)

[David]

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

Jason, I was just following up on this bug.  I noticed that it is still
"done", but I think there are a number of noticible delays still with the
latest trunk.  Should I open a new bug?

Thanks, David

On Sun, Aug 3, 2008 at 9:55 PM, David <david.boon@gmail.com> wrote:

> Hi Jason , I've built latest and and things are better, but noticeably
> sluggish still.  Especially on larger files, but not significantly large.
> For example, I have a file that is 218 lines long, if I hold down C-n and
> count, I can count to 10 before the cursor moves anywhere, and it doesn't
> actually do any moving until I release the keys.
>
> If I do the same 'test' with an older emacs, built from CVS on 02-20-2008,
> I get immediate screen scrolling and cursor movement.
>
>  -David
>
> On Wed, Jul 30, 2008 at 6:15 PM, Emacs bug Tracking System <
> don@donarmstrong.com> wrote:
>
>>
>> This is an automatic notification regarding your bug report
>> which was filed against the emacs,w32 package:
>>
>> #233: Slow repainting, sluggish feeling emacs
>>
>> It has been closed by Jason Rumney <jasonr@gnu.org>.
>>
>> Their explanation is attached below along with your original report.
>> If this explanation is unsatisfactory and you have not received a
>> better one in a separate message then please contact Jason Rumney <
>> jasonr@gnu.org> by
>> replying to this email.
>>
>>
>> --
>> 233: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=233
>> Emacs Bug Tracking System
>> Contact don@donarmstrong.com with problems
>>
>>
>> ---------- Forwarded message ----------
>> From: Jason Rumney <jasonr@gnu.org>
>> To: 233-done@emacsbugs.donarmstrong.com
>> Date: Wed, 30 Jul 2008 23:09:06 +0100
>> Subject: Slow repainting, sluggish feeling emacs
>> reassign 233 emacs,w32
>> thanks
>>
>> It seems that the performance issues are resolved by using uniscribe's
>> built in caching for glyph encoding, and avoiding explicit encoding in
>> the gdi backend.
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: David <david.boon@gmail.com>
>> To: emacs-devel@gnu.org
>> Date: Mon, 12 May 2008 21:10:39 -0400
>> Subject: Slow repainting, sluggish feeling emacs
>> I recently re-built emacs 23 from cvs and there's a noticeable delay in
>> many repainting operations. Typing is sluggish and redrawing a buffer when
>> switching to it is noticeably slow.
>>
>> So I tried to measure the difference.  I started two versions of emacs
>> with --no-init, loaded nothing, and immediately ran elp-instrument-function
>> on "ibuffer".  Here are the results:
>>
>> emacs(GNU Emacs *MailScanner warning: numerical links are often
>> malicious:* 23.0.60.1 <http://23.0.60.1> (i386-mingw-nt5.1.2600) of
>> 2008-02-20 on U0103223-XPA)
>> Function Name Call Count Elapsed Time Average Time
>> ibuffer        1           0.0           0.0
>>
>>
>> GNU Emacs *MailScanner warning: numerical links are often malicious:*23.0.60.1<http://23.0.60.1>(i386-mingw-nt5.1.2600) of 2008-05-12 on U0103223-XPA
>> Function Name Call Count Elapsed Time Average Time
>> ibuffer        1           0.032         0.032
>>
>> I ran elp-instrument-function again and got:
>> ibuffer        1           0.047         0.047
>>
>> The time difference is very small, but with a loaded up emacs config the
>> time becomes very noticeable.
>> I built emacs on windows-xp using cygwin(-mno-cygwin however),
>> ming32-make.  Both versions of the build where 'configured' the same:
>>
>> Here's the 'report-emacs-bug' important stuff:
>>
>>
>> In GNU Emacs *MailScanner warning: numerical links are often malicious:*23.0.60.1<http://23.0.60.1>(i386-mingw-nt5.1.2600)
>>  of 2008-05-12 on U0103223-XPA
>> Windowing system distributor `Microsoft Corp.', version 5.1.2600
>> configured using `configure --with-gcc (3.4) --cflags -I../../include
>> -msse3 -O3'
>>
>> Important settings:
>>   value of $LC_ALL: nil
>>   value of $LC_COLLATE: nil
>>   value of $LC_CTYPE: nil
>>   value of $LC_MESSAGES: nil
>>   value of $LC_MONETARY: nil
>>   value of $LC_NUMERIC: nil
>>   value of $LC_TIME: nil
>>   value of $LANG: ENU
>>   value of $XMODIFIERS: nil
>>   locale-coding-system: cp1252
>>   default-enable-multibyte-characters: t
>>
>> Major mode: Fundamental
>>
>> Minor modes in effect:
>>   tooltip-mode: t
>>   mouse-wheel-mode: t
>>   file-name-shadow-mode: t
>>   global-font-lock-mode: t
>>   blink-cursor-mode: t
>>   global-auto-composition-mode: t
>>   auto-encryption-mode: t
>>   auto-compression-mode: t
>>   line-number-mode: t
>>   transient-mark-mode: t
>>
>> Recent input:
>> M-x M-p i <backspace> e l p 0 <backspace> - i n s t
>> r <tab> f u n <tab> <return> i b u f f e r <return>
>> M-x l o a d - l i <tab> <return> i b u f f e r <return>
>> M-x M-p M-p <return> M-p <return> M-x i b u f f e r
>> <return> q C-x b C-g C-x C-b <down> <down> <down> <down>
>> <down> <down> q C-x 1 M-x i b u f f e r - <M-backspace>
>> e l p - r e s u l <tab> <return> C-SPC <down> M-w q
>> M-x r e p o r <tab> <return>
>>
>> Recent messages:
>> goto-history-element: Beginning of history; no preceding item
>> elp-instrument-function: ELP cannot profile autoloaded function: ibuffer
>> Loading ibuffer...done
>> Updating buffer list...
>> Formats have changed, recompiling...done
>> Mark set
>> Updating buffer list...done
>> Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
>> Quit
>> Mark set
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 7663 bytes --]

bug#233: closed by Jason Rumney <jasonr@gnu.org> (Slow repainting, sluggish feeling emacs)

[Jason Rumney]

David wrote:
> Jason, I was just following up on this bug.  I noticed that it is 
> still "done", but I think there are a number of noticible delays still 
> with the latest trunk.  Should I open a new bug?

Please file a new bug report describing exactly the circumstances under 
which you see delays. The original reporters of this bug no longer see 
the severe slowdown in the circumstances they described.