[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slow output in *compilation* buffer
From: |
Stefan Monnier |
Subject: |
Re: slow output in *compilation* buffer |
Date: |
Wed, 26 Aug 2009 14:56:44 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
>> Ah, I see. So yes, the likely solution is to make compile.el lazier:
>> use font-lock-syntactic-keywords and jit-lock (so the text past the end
>> of the window doesn't need to be scanned right away), and postpone more
>> of the work to next-error.
> elp says that most time is spent in `compilation-error-properties', if
> that helps...
Yes. We should remove the call to previous-single-property-change from
that function and move it to next-error instead.
After all, the property we look for is almost never used, so
this previous-single-property-change takes time O(N) where N is the
amount of output that has already been received. So overall, it causes
an O(N^2) behavior since it is called O(N) times.
>> > BTW, doing the same search with M-x rgrep is MUCH MUCH slower.
>> That sucks. What does rgrep do so differently to make it even worse?
> My guess would be more highlighting: it also highlights the matched
> words on each line.
That's possible, but I'd expect there's something more at play here.
> That means 50974295/4509 = 11305 lookup_char_property calls per
> Fprevious_single_property_change ...
> that sounds a bit excessive.
Since lookup_char_property will be called for each interval (i.e. chunk
of text with the same text-properties) between point and the previous
position where the property of interest is changed (which will usually
be (point-min) in our case), I think it's about right (let's see: 4500
lines, each line has at least 3-4 chunks with different properties, for
a total of about 20000 chunks, so about 10000 scanned per call on
average).
Stefan