Re: Inefficient redisplay

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Thu, 15 Apr 2010 00:38:16 -0400
> 
> AFAIK I need both: nhexl-jit is used to add the hexdump lines to all the
> text that's displayed, whereas the post-command-hook is used to update
> the cursor highlighting (which is why it only updates the overlays on
> the old point position and the new point position).

post-command-hook also invokes nhexl-jit, albeit with different
arguments.  So you may end up doing double work.

> I guess the cursor updating could be more efficient by only changing the
> `face' text-properties on the overlay's before strings rather than
> building new overlays from scratch.  I haven't tried that yet, but I'm
> afraid this will lead to problems because the redisplay code won't
> notice that a before-string was modified so it may forget to redisplay
> the corresponding part of the screen.

Is it really the case that modifying an overlay string does not
trigger redisplay?  That'd be a bug.

> > If invoking nhexl-jit via fontification-functions is really needed,
> > then where do you expect redisplay to invoke it?  IOW, if you make
> > assumptions regarding the value of START and END arguments passed to
> > nhexl-jit by redisplay, what are those assumptions?
> 
> I don't make any particular assumptions about start and end (at least
> not consciously).

But then you should be aware that there's nothing in
fontification-functions or in the redisplay that makes sure they are
only invoked on the displayed portion of the buffer.  As your C-v
experiment proves, it really happens that nhexl-jit is invoked on
portions of the buffer that are outside the window.  And since
nhexl-jit does not validate its arguments against window's first and
last line, it ends up doing unnecessary work.

> >> The behavior I see seems consistent with a situation where the redisplay
> >> "doesn't see" the newlines in the before-strings
> > I don't see any sign that redisplay "doesn't see" the newlines.
> 
> I only say that because the performance behavior is very similar to what
> we get in long-single-line buffers.

I have a few ideas why you get the performance hit, and I will look
into them in a day or two.