Re: slow output in *compilation* buffer

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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