Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Maybe I should rephrase that: why is it important to be a lot faster than
> syntax-ppss?

Ah, I see.  I wouldn't know: I tuned syntax-ppss speed a bit when
I first wrote it, but there's a lot of room for improvement, if needed,
I think.  I haven't done any of that work because I haven't found a need
for it.

> Because speed seems to be the main advantage that Alan's proposal has.

I haven't seen any comparison of Alan's proposal with mine, so I don't
know how they compare.  Their "cost profiles" are quite a bit different
(since my patch re-uses the existing cache whereas his has to fill
another one, but his cache can give him a more immediate answer once
it's filled), so it's not clear to me.

> Would using your syntax-ppss approach instead chip away at the reported 80%
> improvement in the synthetic test, or will it be about as fast?

I'd expect it to be about "same as now" for the normal case, and "same
as Alan's" for the "famous 10s" case.

> (As an aside: we do have `comment-beginning', which delegates to
> syntax-ppss. But it doesn't seem to be widely used.)

IIUC the interesting case is the one where the Elisp code doesn't
actually care about moving outside of a comment.  Instead the need to
skip over a comment comes indirectly via parse-sexp-ignore-comments.
So calling `comment-beginning' is not really an option (and of course
`comment-beginning' does more than find the beginning, since it also
looks for the beginning of the *content* of the comment).

> The latter one gets handled in ruby-syntax-propertize, so I don't know if
> it's relevant.

It's only relevant when it does appear, which should be fairly rare.
In contrast "\n" (the comment ender for the // A comments) appears
fairly often inside a /*...*/ comment.


        Stefan