Re: M-x grep is too slow

[Kim F. Storm]

Stefan Monnier <address@hidden> writes:

> > I tried the above but it finished quite soon.   But, when I tried:
> >         M-x grep -nH -e while emacs/lisp/*/*.el
> > it took long time.
> 
> I see it also.  Grep's output at first comes in fast and then at some point
> it abruptly slows down and then it only comes in a couple chars at a time
> (with enough time inbetween to see the steps).  Later on it switched again
> to "fast" mode, and then switched again to "slow" mode, etc...

I don't see it  (GNU/Linux (redhat9), 1.4 GHz uni-processor)

But it does run SLOOOOW...  In my case, approx 50-70 lines are added per screen 
update.


> 
> The problem is not the time taken in font-lock, but the fact that the text
> gets inserted one char at a time (or maybe 2 or 3 chars, but it should not
> happen that way; and as a matter of fact it does not happen that way when
> grep's output comes in fast).

Well, font-lock definitely makes this A LOT slower...


Looking with a debugger, a lot of time is spent in
previous-single-property-change.

Maybe caching the last position of 'directory and 'message properties
would make a difference ?


Try this little patch:

*** compile.el  20 Jun 2004 20:59:24 +0200      1.322
--- compile.el  16 Jul 2004 16:14:19 +0200      
***************
*** 1200,1206 ****
              (turn-on-font-lock))
          (turn-on-font-lock))
        ;; maybe defer font-lock till after derived mode is set up
!       (run-mode-hooks 'compilation-turn-on-font-lock))))
  
  ;;;###autoload
  (define-minor-mode compilation-shell-minor-mode
--- 1200,1207 ----
              (turn-on-font-lock))
          (turn-on-font-lock))
        ;; maybe defer font-lock till after derived mode is set up
!       ;(run-mode-hooks 'compilation-turn-on-font-lock)
!       )))
  
  ;;;###autoload
  (define-minor-mode compilation-shell-minor-mode

With that, grep runs FAST.


> 
> It seems related to the problem David had with AUCTeX on uniprocessors
> running the Linux kernel with the "interactive" scheduler.  Kim installed
> a patch to fix it, but maybe the patch isn't doing its job here for
> some reason.

If I set process-adaptive-read-buffering to nil this runs even slower for
me, but it still finishes in a couple of minutes...

-- 
Kim F. Storm <address@hidden> http://www.cua.dk