[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug #25608 and the comment-cache branch
From: |
Dmitry Gutov |
Subject: |
Re: Bug #25608 and the comment-cache branch |
Date: |
Mon, 6 Feb 2017 03:28:44 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 |
Hi Alan,
On 04.02.2017 13:02, Alan Mackenzie wrote:
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'd rather it stays in one place, along with any further revisions, if
needed. That should cause less confusion in the long run.
For any casual observers in this discussion who don't want to follow the
links: the patch touches src/syntax.c, and it's 20 lines long.
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.
Ah, so that's what you were arguing against?
Does comment-cache code contain some other functionality that we'd want
to retain while using the syntax-ppss cache? Something that makes
performance overhead of syntax-ppss a problem still?
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" */ /* */ /* '"'" */
^
.
Thank you for the reminder. But do you have any examples that do not
involve narrowing?
Reconciling syntax-ppss with narrowing is a subject of a separate thread
(one that's regrettably stalled for a while, but I'll get back to it
soon). As soon as it's resolved, the Alternative Patch should not have
this problem anymore either.
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
Thanks!
It would seem that differences in speed are not big enough to make any
decision on that basis.
Does that just leave the narrowing issues, or is there something else?
- Re: Bug #25608 and the comment-cache branch, (continued)
- Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/13
- Re: Bug #25608 and the comment-cache branch, zhanghj, 2017/02/13
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/12
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/13
- Re: Bug #25608 and the comment-cache branch, Eli Zaretskii, 2017/02/13
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/13
Re: Bug #25608 and the comment-cache branch, Dmitry Gutov, 2017/02/02
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/03
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/05
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/06
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/06
- Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/07
- Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/08
Re: Bug #25608 and the comment-cache branch, Eli Zaretskii, 2017/02/07
Re: Bug #25608 and the comment-cache branch, Alan Mackenzie, 2017/02/07
Re: Bug #25608 and the comment-cache branch, Eli Zaretskii, 2017/02/08
Re: Bug #25608 and the comment-cache branch, Stefan Monnier, 2017/02/02