[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Low redisplay performance (23 regression)

From: Stefan Monnier
Subject: Re: Low redisplay performance (23 regression)
Date: Wed, 29 Apr 2009 16:20:49 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

>> > As I use `end-of-defun' in my customized
>> > `font-lock-extend-region-functions' this does have an impact on the
>> > overall performance of fontification for me on large files.
>> I don't think the size of the file (aka buffer) should make
>> a difference.

> Yes, I meant to write on large defuns. I test this on a file which
> contains defuns spanning up to 500-600 lines.

Yes, that makes sense.

> I'm not sure how much you can do with this information. But I can concur
> with the OP that there does seem to be a performance regression.

Indeed font-lock-fontify-keywords-region (which is the part which I'd
expect to take the bulk of the time and would be a source of performance
problems no matter how you implement your
font-lock-extend-region-functions if you force refontification of the
whole defun every time), so as I was saying
font-lock-fontify-keywords-region got about twice as slow.  And I can't
explain it.  As far as I know, this part of font-lock has not been
changed in any significant way.  What happens if you use Emacs-22's
font-lock.el in Emacs-23?

> > So it's about twice as slow for this test, which is the expected in this
> > case: since your benchmark always calls it with point between 2 defuns,
> > it ends up doing: BOD-raw to find the previous defun, EOD-function to
> > find its end, which tells Emacs that the starting point was after the
> > previous defun, so it calls BOD-raw again to find the next defun and
> > finally EOD-function to get to its end.
> Why didn't 22.x do this? Probably to fix some bug, right?

No, you're right.  Emacs-22's code is very different, but it should end
up doing pretty much the same thing (two calls to BOD-raw plus two calls
to forward-list) and I see no reason why it should be any faster.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]