GNU Emacs 24 Performance Issues in 'add-text-properties

GNU Emacs 24 Performance Issues in 'add-text-properties

[joseph.koziatek]

Hello All,

Recently I started using Gnu Emacs 24.3.1 on Redhat 5 which I built with X support. I've noticed that add-text-properties has a performance issue. Below is a simplified function I wrote many years ago to gray out C & C++ comments. I call it from find-file-hooks and other commands where I select a buffer to edit.
 
In Gnu Emacs 21.4.1 this routine is blistering fast on a buffer of C++ code 11,000 lines long with lots of comments. Under Gnu Emacs 24.3.1 I experience a long delay.. 

If I comment out the calls to 'add-text-properties under 24.3.1, it is super fast, so the 'search-forward commands are not the bottleneck.  

It is the calls to 'add-text-properties causing the long delay.

The memory usage (virtual memory and physical memory) reported by ps aux --sort=-rss,-rss looks normal for both versions (VirtMemory=150Mb and Rss=30Mb)  

I'm running on a 16 Cpu box with 32 Gig ram, so I have plenty of horsepower.

Any help as to what can be causing this code to run so slow under Gnu Emacs 24 is greatly appreciated. 

Thanks In Advance 
Joe

===================================================================

(setq comm-start  "/*" ) 
(setq comm-end    "*/" )
(setq slash2      "//" )

(defun mark-comments ()   ;; highlight all C comments...
  (interactive)
    
       (setq savepos (point))
       (goto-char (point-min))
  
       (setq startc (search-forward comm-start nil t))
       (setq endc   (search-forward comm-end   nil t))
       (while (and startc endc)
           (add-text-properties (- startc 2) (- endc 0)  '(face           '(:foreground  "gray")))
           (add-text-properties (- startc 2) (- endc 0)  '(rear-nonsticky t) )
           (add-text-properties (- startc 2) (- endc 0)  '(front-sticky t) )

           (setq startc (search-forward comm-start nil t))
           (setq endc   (search-forward comm-end   nil t))
       )
    
       (goto-char (point-min))
       (setq startc (search-forward slash2 nil t))
       (while startc
          (end-of-line) 
          (add-text-properties (- startc 2 ) (point)  '(face           '(:foreground  "gray")))
          (add-text-properties (- startc 2 ) (point)  '(rear-nonsticky t) )
          (add-text-properties (- startc 2 ) (point)  '(front-sticky t) )

          (setq startc (search-forward slash2 nil t))
       )
       (goto-char savepos)
    t
) 

Re: GNU Emacs 24 Performance Issues in 'add-text-properties

[Stefan Monnier]

>            (add-text-properties (- startc 2) (- endc 0)  '(face           '(:foreground  "gray")))

This call, like any other call that changes text-properties is
considered as a buffer modification.  So the modification hooks are run,
which can include font-lock stuff (which will end up overwriting your
`face' property, by the way) and other fun, which could end up
being costly.


        Stefan

Re: GNU Emacs 24 Performance Issues in 'add-text-properties

[joseph.koziatek]

On Wednesday, September 3, 2014 4:19:23 PM UTC-4, joseph....@dowjones.com wrote:
> Hello All,
> 
> 
> 
> Recently I started using Gnu Emacs 24.3.1 on Redhat 5 which I built with X support. I've noticed that add-text-properties has a performance issue. Below is a simplified function I wrote many years ago to gray out C & C++ comments. I call it from find-file-hooks and other commands where I select a buffer to edit.
> 
>  
> 
> In Gnu Emacs 21.4.1 this routine is blistering fast on a buffer of C++ code 11,000 lines long with lots of comments. Under Gnu Emacs 24.3.1 I experience a long delay.. 
> 
> 
> 
> If I comment out the calls to 'add-text-properties under 24.3.1, it is super fast, so the 'search-forward commands are not the bottleneck.  
> 
> 
> 
> It is the calls to 'add-text-properties causing the long delay.
> 
> 
> 
> The memory usage (virtual memory and physical memory) reported by ps aux --sort=-rss,-rss looks normal for both versions (VirtMemory=150Mb and Rss=30Mb)  
> 
> 
> 
> I'm running on a 16 Cpu box with 32 Gig ram, so I have plenty of horsepower.
> 
> 
> 
> Any help as to what can be causing this code to run so slow under Gnu Emacs 24 is greatly appreciated. 
> 
> 
> 
> Thanks In Advance 
> 
> Joe
> 
> 
> 
> ===================================================================
> 
> 
> 
> (setq comm-start  "/*" ) 
> 
> (setq comm-end    "*/" )
> 
> (setq slash2      "//" )
> 
> 
> 
> (defun mark-comments ()   ;; highlight all C comments...
> 
>   (interactive)
> 
>     
> 
>        (setq savepos (point))
> 
>        (goto-char (point-min))
> 
>   
> 
>        (setq startc (search-forward comm-start nil t))
> 
>        (setq endc   (search-forward comm-end   nil t))
> 
>        (while (and startc endc)
> 
>            (add-text-properties (- startc 2) (- endc 0)  '(face           '(:foreground  "gray")))
> 
>            (add-text-properties (- startc 2) (- endc 0)  '(rear-nonsticky t) )
> 
>            (add-text-properties (- startc 2) (- endc 0)  '(front-sticky t) )
> 
> 
> 
>            (setq startc (search-forward comm-start nil t))
> 
>            (setq endc   (search-forward comm-end   nil t))
> 
>        )
> 
>     
> 
>        (goto-char (point-min))
> 
>        (setq startc (search-forward slash2 nil t))
> 
>        (while startc
> 
>           (end-of-line) 
> 
>           (add-text-properties (- startc 2 ) (point)  '(face           '(:foreground  "gray")))
> 
>           (add-text-properties (- startc 2 ) (point)  '(rear-nonsticky t) )
> 
>           (add-text-properties (- startc 2 ) (point)  '(front-sticky t) )
> 
> 
> 
>           (setq startc (search-forward slash2 nil t))
> 
>        )
> 
>        (goto-char savepos)
> 
>     t
> 
> )


Hello Stefan, 

Thanks for your response. This does work well with no interference from font-lock-mode because I turn and keep font-lock-mode off when I edit C/C++.  Actually, I wrote the commenting because font-lock-mode is too slow on large C/C++ files.  

Also, my real routine handles "modification" status and I use the post-command-hook for real-time commenting as I type, all of which is blistering fast running under Emacs 21.4.1 . 

Under Emacs 24.3.1 linux "top" shows the %CPU at 100.0 for 5 seconds when I run on 11,000 lines. There is no delay under Emacs 21.4.1 (running same code) as it is instantaneous.

As an experiment, I built Gnu Emacs 22.3 from source on the same box and it has the same slowness (taking 5 full seconds on 11,000 lines). 

I guess I will have to live with this. I wonder if it has something to do with the fact that the versions I built from source are slow?  I know Emacs 21.4.1 came from the Redhat 5 installation procedure.. 

Joe 

  











 by using (buffer-modified-p) and resetting with  (set-buffer-modified-p arg).  

Re: GNU Emacs 24 Performance Issues in 'add-text-properties

[Stefan Monnier]

> Actually, I wrote the commenting because font-lock-mode is too slow on large
> C/C++ files.

Performance of c-mode's highlighting on large files can indeed be
problematic.  This said, Emacs's own src/xdisp.c (1MB, 30K lines) is
a test case which Emacs maintainers use on a regular basis
(intentionally or not), so we try to fix those problems, and we
generally consider them as bugs.

If you have a file where Emacs's major mode suffers from performance
problems, please M-x report-emacs-bug.  It's not always easy to fix, but
we do try to find some solution.

> Thanks for your response. This does work well with no interference from
> font-lock-mode because I turn and keep font-lock-mode off when I edit C/C++.

When I try your code on my machine (on Emacs's src/xdisp.c, with
font-lock disabled), it indeed takes a few seconds to run in c-mode, but
is "instantaneous" in fundamental-mode.  Running it twice in succession in
c-mode, only the first run is slow.

Running it through M-x profiler-start, I get the following profile:

- command-execute                                                5900  98%
 - call-interactively                                            5900  98%
  - execute-extended-command                                     5773  96%
   - command-execute                                             5760  96%
    - call-interactively                                         5760  96%
     - mark-comments                                             5744  95%
      - while                                                    5740  95%
       - add-text-properties                                     5704  95%
        - c-after-change                                         5012  83%
         - let*                                                  4996  83%
          - unwind-protect                                       4996  83%
           - progn                                               4996  83%
            - save-restriction                                   4996  83%
             - let                                               4996  83%
              - unwind-protect                                   4992  83%
               - progn                                           4984  83%
                - save-excursion                                 4808  80%
                 - mapc                                          4808  80%
                  - #<lambda 0xe067877>                          4808  80%
                   - funcall                                     4808  80%
                    - c-neutralize-syntax-in-and-mark-CPP        4800  80%
                    ...

so as you can see, even though I did disable font-lock-mode, c-mode
still has an after-change-function installed (probably used because
syntactic info is also needed for indentation and is cached to avoid
terrible slowdowns in large files) and it takes the lion's share of
the time.


        Stefan