for the record, i narrowed this down to the maven element of
`compilation-error-regexp-alist'. if i remove that element,
`compilation-mode' is fast on the minimal test case in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25682 .

it's evidently a somewhat known issue:
https://blog.danielgempesaw.com/post/129841682030/fixing-a-laggy-compilation-buffer
https://www.reddit.com/r/emacs/comments/2b2j5m/emacs_unresponsive_during_compilebuild/
http://comments.gmane.org/gmane.emacs.bugs/28783  (currently down)


On Sat, Feb 11, 2017 at 3:09 PM Anders Lindgren <andlind@gmail.com> wrote:

> Since it's slow in Fundamental mode as well, it's unrelated to
>> font-lock, and thus to this thread.  Display of very long lines is
>> known to be slow in Emacs.
>>
>
> I believe this is a font-lock problem. If you disable
> global-font-lock-mode before you open the file, it opens in seconds. If
> global-font-lock-mode is active Emacs stops responding (I gave up after a
> few minutes).
>
> A quick experiment suggested that the problem is the member
> `font-lock-extend-region-wholelines' of `font-lock-extend-region-functions'
> that ensures that whenever font-lock highlights keywords in a region, the
> full line is rehighlighted (in the case of the example, the full 18M). By
> removing it, font-locking the file is done in seconds. (I assume that only
> the visible parts of the buffer is highlighted.)
>
> Clearly, simple dropping the function is not a good idea, as keyword
> fontification could start anywhere on the line, e.g. in the middle of
> identifiers. A better approach would be to extend the region to include
> 10KB in either direction, plus ensure that the region isn't split in the
> middle of identifiers.
>
>    / Anders
>
> Ps. In case anybody is interested in looking further into this, you can
> use the tool https://github.com/Lindydancer/highlight-refontification to
> get visual feedback on the font-lock refontification process.
>
>

-- 
https://snarfed.org/