Eli Zaretskii <e...@gnu.org> writes: >> From: Alex Bennée <alex.ben...@linaro.org> >> Cc: Stefan Monnier <monn...@iro.umontreal.ca>, 23...@debbugs.gnu.org, >> rpl...@gmail.com, jwieg...@gmail.com, nljlistb...@gmail.com >> Date: Tue, 19 Jul 2016 18:05:37 +0100 >> >> > Do we care that using save-match-data in every call to replace-match >> > might mean a performance hit? If it will, then this will again punish >> > most of the users for the benefit of those few who (1) have >> > buffer-modification hooks, and (2) those hooks call save-match-data. >> >> I care unless there is an easy way to identify which buffer modification >> hooks are responsible so I can take steps as a user to mitigate the >> problems. > > Any hook in before-change-functions or after-change-functions that > calls save-match-data. > > If we care about the performance hit, we need to come up with a > different solution for this problem (or measure the performance hit > and convince ourselves it is not a big deal).
Thanks for the hint. So in my case it was flycheck-handle-change which was triggering the problem: (defun flycheck-handle-change (beg end _len) "Handle a buffer change between BEG and END. BEG and END mark the beginning and end of the change text. _LEN is ignored. Start a syntax check if a new line has been inserted into the buffer." ;; Save and restore the match data, as recommended in (elisp)Change Hooks (save-match-data (when flycheck-mode ;; The buffer was changed, thus clear the idle timer (flycheck-clear-idle-change-timer) (if (string-match-p (rx "\n") (buffer-substring beg end)) (flycheck-buffer-automatically 'new-line 'force-deferred) (setq flycheck-idle-change-timer (run-at-time flycheck-idle-change-delay nil #'flycheck-handle-idle-change)))))) However it doesn't look as though it tweaks the buffer until idle timer has run. Weird.... -- Alex Bennée