bug#26079: 26.0.50; Performance regression in delete-trailing-whitespace

[npostavs]

tags 26079 confirmed
quit

Sho Takemori <stakemorii@gmail.com> writes:

> Dear developers,
>
> delete-trailing-whitespace in Emacs 26 for large files is very slow.
>
> For example, it took about 1.6s for this file 
> (https://raw.githubusercontent.com/stakemori/e8theta_degree3/master/results/wt18_17_5/wt18_17_5.org).
> But in Emacs 25, it took about 0.003s.
> A similar code to the following is used in delete-trailing-whitespace. And it 
> is slow for large files.
>
> (save-excursion
> (let ((end-marker nil))
> (goto-char (point-min))
> (with-syntax-table (make-syntax-table (syntax-table))
> (modify-syntax-entry ?\f "_")
> (modify-syntax-entry ?\n "_")
> (re-search-forward "\\s-+$" end-marker t))))

It seems that this regex causes a lot of backtracking when \n is not
whitespace.  It was introduced in [1: 7c6317a049]; restoring the
strategy from before seems make it fast again.  Michal, do you think
that's the best way to fix this?

---   i/lisp/simple.el
+++   i/lisp/simple.el
@@ -632,12 +632,11 @@ delete-trailing-whitespace
         (goto-char (or start (point-min)))
         (with-syntax-table (make-syntax-table (syntax-table))
           ;; Don't delete formfeeds, even if they are considered whitespace.
           (modify-syntax-entry ?\f "_")
-          ;; Treating \n as non-whitespace makes things easier.
-          (modify-syntax-entry ?\n "_")
-          (while (re-search-forward "\\s-+$" end-marker t)
-            (let ((b (match-beginning 0)) (e (match-end 0)))
+          (while (re-search-forward "\\s-$" end-marker t)
+            (skip-syntax-backward "-" (line-beginning-position))
+            (let ((b (point)) (e (match-end 0)))
               (when (region-modifiable-p b e)
                 (delete-region b e)))))
         (if end
             (set-marker end-marker nil)


1: 2016-07-04 23:44:06 +0200 7c6317a0498b6690ea668909ac012cb45e6f809b
  Simplify ‘delete-trailing-whitespace’ by not treating \n as whitespace