emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug #25608 and the comment-cache branch


From: Alan Mackenzie
Subject: Re: Bug #25608 and the comment-cache branch
Date: Sat, 4 Feb 2017 11:02:59 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello, Dmitry.

On Fri, Feb 03, 2017 at 23:53:31 +0200, Dmitry Gutov wrote:
> On 03.02.2017 18:44, Alan Mackenzie wrote:

> > Perhaps, for clarity's sake, you could post this alternative patch here,
> > or if it's big, put it into a scratch branch.  Then, at least we'll all
> > know that we're talking about the same thing.

> I've already posted the url.

You did, indeed.  Apologies.

> The path is in the comments of the bug you're purportedly trying to
> fix. So here is the message you unlimately ignored:
> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg01075.html

> If the patch is not good enough for some reasons, please post those, 
> with specific examples. And I'm sure we can improve it.

I think it would be useful to post the actual patch here, so it can be
more easily discussed, and to be easier for people who want to try it
out to get to it.

> > I'm not sure what you want them for.

> To see how they compare performance-wise, at least. "syntax-ppss cache 
> is slow" was one of the big reasons for introducing the text property 
> cache implemented via text properties, written in C, IIRC.

syntax-ppss being too slow was its use in a specific circumstance.  That
was trying to use it in place of comment-cache's cache mechanism, but
otherwise using comment-cache.  That would result in ~2 orders of
magnitude slowdown in backward_comment.

> So you should be able to demonstrate this stark difference in performance.

That would involve hacking comment-cache, and as I've said before, would
be a fruitless waste of time.  With syntax-ppss we'd end up having to
scan forward 10,000 characters (on average) with parse-partial-sexp just
to be able to scan back over an 80 character comment.  That's obvious,
and not worth timing.

> > The "alternative patch" didn't scan comments correctly all the time
> > when I looked at it, just as the current back_comment doesn't.

> Please remind us of the specific problems it has.

In the following test case (same as in my other post) the "alternative
patch" doesn't work.  Narrow the buffer with point-min at the indicated
position.  Put point at EOL.  Try M-: (forward-comment -1).  This fails.

    char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /*  */  /*   '"'"  */
                      ^

.

> > and I'll do it.

Using M;- (time-scroll) from the start of xdisp.c, and (time-scroll t)
from its end (having cleared caches by typing a character at BOB), I get
these timings

                      forward              backward
master                 34.51s               36.43s
comment-cache          33.68s               32.81s
"alternative patch"    35.49s               36.05s


(defmacro time-it (&rest forms)
  "Time the running of a sequence of forms using `float-time'.
Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
  `(let ((start (float-time)))
    ,@forms
    (- (float-time) start)))

(defun time-scroll (&optional arg)
  (interactive "P")
  (message "%s"
           (time-it
            (condition-case nil
                (while t
                  (if arg (scroll-down) (scroll-up))
                  (sit-for 0))
              (error nil)))))


It would seem that differences in speed are not big enough to make any
decision on that basis.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]