Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch

[Dmitry Gutov]

On 13.02.2014 18:42, Stefan Monnier wrote:
> Just `set-buffer' might be faster, indeed, but mostly because it's
> written in C (e.g. it also has to iterate through the local variables to
> save the old value and reload the new value for some of them).

Not the 100+ of them, though?

> But then you have to add things like the need to handle variables that
> are buffer-local but should be shared among the indirect buffers, and
> I doubt the end result will be faster.  Plus handle all the bugs that
> indirect buffers introduce (e.g. a modification in one of the indirect
> buffers only runs its own after-change-functions, not the one of the
> base buffer or any of the other indirect buffers; overlays added by
> a major/minor mode in its indirect buffer won't affect the display of
> the base buffer; ...).

This clearly calls for introduction of base-buffer-local variables!

Half-kidding aside, yeah, it sounds like indirect buffers might need 
some bugfixing to be usable as a building block for mmm-mode.

> Hmm... I wonder why mmm-save-local-variables is defined the way it is.
> It doesn't seem to make use of `buffer-local-variables', even though it's
> the most natural starting point.  E.g. there shouldn't be a need to list
> explicitly all the c-* variables.  Maybe the author didn't know about
> buffer-local-variables (or it didn't exist back then)?

I'm not quite sure, but this way we only save the variables that are 
known to be safe in the multiple-mode context. And also don't touch 
anything mmm-mode itself introduced. For non-cc-engine modes, the lists 
of variables to save are quite short, on the order of ~30 items.

Apparently I was even wrong about saving and restoring being the slow 
part: `mmm-update-submode-region', which includes the calls to 
`mmm-save-changed-local-variables' and `mmm-set-local-variables', is 
faster than simply calling `buffer-local-variables'.

In a mixed-mode test file:

(js2-time (dotimes (_ 1000) (buffer-local-variables))) => 0.098

(js2-time (dotimes (_ 1000) (mmm-update-submode-region))) => 0.055

^- the latter was without the check "if mode unchanged, do nothing".

Now that I've checked, parsing the buffer into regions is definitely the 
slowest part (followed by fontification, which takes about 40% of the 
time in the current test example):

(js2-time (dotimes (_ 1000) (mmm-parse-buffer))) => 7.97

^- includes both `mmm-apply-classes' and `mmm-refontify-maybe'.

And it's a 30-line file.