w32 redisplay lags much more seriously when editing big files.

w32 redisplay lags much more seriously when editing big files.

[Kevin Yu]

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

Hi, All
     The performance issue of new backend on w32 has been talked a lot on
this list. If you hold down the "C-n", you will see half of the window is
blank when the cursor goes over the bottom line of window. I have tried it
on a big file with 20000 lines. It lags much more in a big file than a small
file (about 2000 lines). So the file size will affected redisplay time?
     I wish it'll help you guys to improve the performance on w32.
     Best wishes.

Kevin

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

Re: w32 redisplay lags much more seriously when editing big files.

[Kyle M. Lee]

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

2008/7/23 Kevin Yu <yujie052@gmail.com>:

> Hi, All
>      The performance issue of new backend on w32 has been talked a lot on
> this list. If you hold down the "C-n", you will see half of the window is
> blank when the cursor goes over the bottom line of window.
>

This is a known issue. I care about this too. Though I closed my eyes to
take a break when I pressed C-n . :-)


> I have tried it on a big file with 20000 lines. It lags much more in a big
> file than a small file (about 2000 lines). So the file size will affected
> redisplay time?
>      I wish it'll help you guys to improve the performance on w32.
>

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

Fwd: w32 redisplay lags much more seriously when editing big files.

[David]

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

I've been building the latest from CVS for a few months now.  Everytime I
try to run my local build, I have to stop because I can't stand the sluggish
refresh.  There appears to be something very wrong, but there's been very
little chatter about it lately.

I wonder if there's any status?



On Wed, Jul 23, 2008 at 6:51 AM, Kyle M. Lee <mail2kyle@gmail.com> wrote:

>
>
> 2008/7/23 Kevin Yu <yujie052@gmail.com>:
>
>> Hi, All
>>      The performance issue of new backend on w32 has been talked a lot on
>> this list. If you hold down the "C-n", you will see half of the window is
>> blank when the cursor goes over the bottom line of window.
>>
>
> This is a known issue. I care about this too. Though I closed my eyes to
> take a break when I pressed C-n . :-)
>
>
>>  I have tried it on a big file with 20000 lines. It lags much more in a
>> big file than a small file (about 2000 lines). So the file size will
>> affected redisplay time?
>>      I wish it'll help you guys to improve the performance on w32.
>>
>
>

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

Re: Fwd: w32 redisplay lags much more seriously when editing big files.

[Chong Yidong]

David <david.boon@gmail.com> writes:

> I've been building the latest from CVS for a few months now.  Everytime I try
> to run my local build, I have to stop because I can't stand the sluggish
> refresh.  There appears to be something very wrong, but there's been very
> little chatter about it lately. 
>
> I wonder if there's any status?

I have no clue what causes this bug.  If anyone on this list can share
some ideas, no matter how vague, that would be nice.

Re: Fwd: w32 redisplay lags much more seriously when editing big files.

[finalpatch]

Chong Yidong <cyd <at> stupidchicken.com> writes:

> 
> David <david.boon <at> gmail.com> writes:
> 
> > I've been building the latest from CVS for a few months now.  Everytime I try
> > to run my local build, I have to stop because I can't stand the sluggish
> > refresh.  There appears to be something very wrong, but there's been very
> > little chatter about it lately. 
> >
> > I wonder if there's any status?
> 
> I have no clue what causes this bug.  If anyone on this list can share
> some ideas, no matter how vague, that would be nice.
> 
> 


i did a -pg build last night and played with the executable a bit. here's the
first few lines of the gprof output. i'm not sure if it's normal for
"mark_object" to use so many cpu cycles but i'm not familiar with the code
anyway. if anybody is interested i'll be glad to send him the complete file.

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 22.13      0.68     0.68 28772710     0.00     0.00  mark_object
  7.87      0.92     0.24  1020457     0.00     0.00  re_match_2_internal
  7.87      1.16     0.24   219620     0.00     0.00  Fbyte_code
  3.61      1.26     0.11       44     2.50    19.57  Fgarbage_collect
  3.28      1.37     0.10  3318374     0.00     0.00  lookup_char_property
  2.46      1.44     0.07  5414804     0.00     0.00  char_table_ref
  1.97      1.50     0.06  1139532     0.00     0.00  find_interval
  1.97      1.56     0.06   368425     0.00     0.00  Fstring_equal
  1.97      1.62     0.06   174135     0.00     0.00  oblookup
  1.97      1.68     0.06    45620     0.00     0.00  re_compile_pattern
  1.64      1.73     0.05   522580     0.00     0.00  get_next_display_element
  1.64      1.78     0.05   518320     0.00     0.00  x_produce_glyphs
  1.64      1.83     0.05   476645     0.00     0.00  overlays_at
  1.64      1.88     0.05   149496     0.00     0.00  mark_vectorlike
  1.64      1.93     0.05     4820     0.01     0.03  scan_lists
  1.31      1.97     0.04  3012374     0.00     0.00  Fassq
  1.31      2.01     0.04    18081     0.00     0.01  move_it_in_display_line_to
  1.15      2.04     0.04  2094433     0.00     0.00  multibyte_char_to_unibyte_safe
  0.98      2.08     0.03  5340008     0.00     0.00  Fcdr
  0.98      2.11     0.03  4210881     0.00     0.00  marker_position
  0.98      2.13     0.03   866237     0.00     0.00  Ffuncall
  0.98      2.17     0.03   290191     0.00     0.00  _malloc_internal_nolock
  0.98      2.19     0.03   218045     0.00     0.00  re_search_2
  0.98      2.23     0.03     5185     0.01     0.01  display_line
  0.82      2.25     0.03  1698196     0.00     0.00  specbind
  0.66      2.27     0.02  2689926     0.00     0.00  readbyte_from_file
  0.66      2.29     0.02  1182370     0.00     0.00  balance_an_interval
  0.66      2.31     0.02   657759     0.00     0.00  validate_interval_range
  0.66      2.33     0.02   500962     0.00     0.00  w32font_text_extents
  0.66      2.35     0.02   345517     0.00     0.00  sort_overlays
  0.66      2.37     0.02   265967     0.00     0.00  _free_internal_nolock
  0.66      2.39     0.02   215633     0.00     0.00  read1
  0.66      2.41     0.02   175616     0.00     0.00  update_syntax_table
  0.66      2.43     0.02   174135     0.00     0.00  hash_string
  0.66      2.45     0.02   114131     0.00     0.00  assq_no_quit
  0.66      2.47     0.02    89724     0.00     0.00  concat
  0.66      2.49     0.02    20650     0.00     0.00  stat
  0.66      2.51     0.02     3365     0.01     0.01  xrdb_get_resource
  0.49      2.52     0.01   797360     0.00     0.00  char_quoted
  0.49      2.54     0.01                             valid_lisp_object_p
  0.33      2.55     0.01  3190277     0.00     0.00  readchar
  0.33      2.56     0.01  1865738     0.00     0.00  re_iswctype

Re: Fwd: w32 redisplay lags much more seriously when editing big files.

[Chong Yidong]

finalpatch <fengli@gmail.com> writes:

> i did a -pg build last night and played with the executable a
> bit. here's the first few lines of the gprof output. i'm not sure if
> it's normal for "mark_object" to use so many cpu cycles but i'm not
> familiar with the code anyway. if anybody is interested i'll be glad
> to send him the complete file.

Thanks very much.

Could you compile a similar list on GNU/Linux, for comparison?