Explain syntax-ppss-stats please

Explain syntax-ppss-stats please

[Lennart Borgman (gmail)]

I do not understand the use of syntax-ppss-stats at all. Where is it 
used? (I can only see that the 5:th element is read.) How does it work?

Re: Explain syntax-ppss-stats please

[Stefan Monnier]

> I do not understand the use of syntax-ppss-stats at all. Where is it used?
> (I can only see that the 5:th element is read.) How does it work?

Only the 5th element is really used.  The rest was added there during
development to tune the algorithm.  It could be removed.

As for the 5th element it's used to keep track of the average size of
a "defun", so as to know whether to use the closest cache location, or
to try and find a closer location with syntax-begin-function: if the
closest cache location is 100KB earlier and syntax-begin-function
usually finds a safe point within 10KB, we're better off calling
syntax-begin-function (when tho it'll typically take a while itself)
than running parse-partial-sexp on the 100KB.  But OTOH if
syntax-begin-function usually needs to look back 200KB to find a safe
spot, then just the call to syntax-begin-function might take us longer
than just running parse-partial-sexp on the 100KB.


        Stefan

Re: Explain syntax-ppss-stats please

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> I do not understand the use of syntax-ppss-stats at all. Where is it used?
>> (I can only see that the 5:th element is read.) How does it work?
> 
> Only the 5th element is really used.  The rest was added there during
> development to tune the algorithm.  It could be removed.

Thanks. I still believe too much in magic. I thought something strange 
was going on somewhere behind the scenes.

Maybe this could be told in the code and the lines changing the other 
elements commented out?


> As for the 5th element it's used to keep track of the average size of
> a "defun", so as to know whether to use the closest cache location, or
> to try and find a closer location with syntax-begin-function: if the
> closest cache location is 100KB earlier and syntax-begin-function
> usually finds a safe point within 10KB, we're better off calling
> syntax-begin-function (when tho it'll typically take a while itself)
> than running parse-partial-sexp on the 100KB.  But OTOH if
> syntax-begin-function usually needs to look back 200KB to find a safe
> spot, then just the call to syntax-begin-function might take us longer
> than just running parse-partial-sexp on the 100KB.

Thanks, this was helpful.