unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* Processed: Slow repainting, sluggish feeling emacs
       [not found] <4890E682.6090108@gnu.org>
@ 2008-07-30 22:15 ` Emacs bug Tracking System
       [not found] ` <475204970805121810y5edc513by93a0fdbcd2ca557@mail.gmail.com>
  1 sibling, 0 replies; 5+ messages in thread
From: Emacs bug Tracking System @ 2008-07-30 22:15 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Bugs, w32 #233

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)





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#233: marked as done (Slow repainting, sluggish feeling emacs)
       [not found] ` <475204970805121810y5edc513by93a0fdbcd2ca557@mail.gmail.com>
@ 2008-07-30 22:15   ` Emacs bug Tracking System
       [not found]   ` <handler.233.D233.121745578020803.notifdone@emacsbugs.donarmstrong.com>
  1 sibling, 0 replies; 5+ messages in thread
From: Emacs bug Tracking System @ 2008-07-30 22:15 UTC (permalink / raw)
  To: Jason Rumney

[-- 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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#233: closed by Jason Rumney <jasonr@gnu.org> (Slow repainting, sluggish feeling emacs)
       [not found]   ` <handler.233.D233.121745578020803.notifdone@emacsbugs.donarmstrong.com>
@ 2008-08-04  1:55     ` David
  2008-08-31 12:39       ` David
  0 siblings, 1 reply; 5+ messages in thread
From: David @ 2008-08-04  1:55 UTC (permalink / raw)
  To: 233

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#233: closed by Jason Rumney <jasonr@gnu.org> (Slow repainting, sluggish feeling emacs)
  2008-08-04  1:55     ` bug#233: closed by Jason Rumney <jasonr@gnu.org> " David
@ 2008-08-31 12:39       ` David
  2008-08-31 12:53         ` Jason Rumney
  0 siblings, 1 reply; 5+ messages in thread
From: David @ 2008-08-31 12:39 UTC (permalink / raw)
  To: 233, jasonr

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#233: closed by Jason Rumney <jasonr@gnu.org> (Slow repainting, sluggish feeling emacs)
  2008-08-31 12:39       ` David
@ 2008-08-31 12:53         ` Jason Rumney
  0 siblings, 0 replies; 5+ messages in thread
From: Jason Rumney @ 2008-08-31 12:53 UTC (permalink / raw)
  To: David; +Cc: 233

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.







^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-08-31 12:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <4890E682.6090108@gnu.org>
2008-07-30 22:15 ` Processed: Slow repainting, sluggish feeling emacs Emacs bug Tracking System
     [not found] ` <475204970805121810y5edc513by93a0fdbcd2ca557@mail.gmail.com>
2008-07-30 22:15   ` bug#233: marked as done (Slow repainting, sluggish feeling emacs) Emacs bug Tracking System
     [not found]   ` <handler.233.D233.121745578020803.notifdone@emacsbugs.donarmstrong.com>
2008-08-04  1:55     ` bug#233: closed by Jason Rumney <jasonr@gnu.org> " David
2008-08-31 12:39       ` David
2008-08-31 12:53         ` Jason Rumney

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).