Re: Inefficient redisplay

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Mon, 12 Apr 2010 17:46:21 -0400
> Cc: address@hidden
> 
> Several problems:
> 1- it seems that I'm not able to have position N displayed without
>    having all positions 1..N with fontified set to non-nil (I.e. I have
>    to have all the prefix of the buffer fontified).  That's a major
>    problem since I use overlays: if N is large, that implies a large
>    number of overlays, which implies serious performance problems.
> 2- performance sucks.  Maybe it's because of 1, but it's probably not
>    only due to that, because performance is better when I go back to the
>    beginning of the buffer (which doesn't remove overlays).

I don't think the amount of overlays is the reason for 2.  My evidence
is that if I invoke nhexl-flush-overlays manually, performance does
not improve a bit.

I started looking at what nhexl-mode does, and I'm puzzled by the
logic of its design.  Why do you arrange for nhexl-jit to be called
via fontification-functions, if you also have it on post-command-hook?
Is one of them a remnant of an idea that was rejected? if so, which
one?  If you really do need both, can you explain why?

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?

> 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.  The
mere fact that you see several lines on the screen is the proof that
redisplay did see the newlines: that's how it knows that one line ends
and another begins.

I think performance "sucks" for a different reason, but I don't yet
know what it is.