GNU bug report logs - #24048
25.0.95; syntax-ppss can be slow

Previous Next

Full log

Message #8 received at 24048 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Aaron Jensen <aaronjensen <at> gmail.com>, 24048 <at> debbugs.gnu.org
Subject: Re: bug#24048: 25.0.95; syntax-ppss can be slow
Date: Mon, 25 Jul 2016 04:16:45 +0300

Hi Aaron,

On 07/21/2016 05:29 PM, Aaron Jensen wrote:
>
> In certain situations, the caching of syntax-ppss can seem to be
> insufficient for good performance when syntax-ppss is invoked in a tight
> loop. smartparens is a popular package that currently invokes
> syntax-ppss in a tight loop (about 30-100 times depending on how many
> match pairs are configured). syntax-ppss has caching built in, but it is
> willing to use a cache from a further back position and do a
> `parse-partial-sexp` from the old position to the current. Afterwards,
> it does not set the cache with the current position. As such, in the
> pathological case, it can parse ~2000 characters 30-100 times in a tight
> loop. This is slow enough to show up in profiling and affect typing
> latency.
>
> To repro, install:
>
> smartparens (you can use
> https://github.com/aaronjensen/smartparens/tree/limit-binding-of-case-fold-search
> to alleviate a different performance issue which could distract in the
> profiling)
> elixir-mode

Is there a way to reproduce it more easier? Maybe without smartparens, 
just with elixir-mode, if it's sufficient to illustrate the performance 
problem (I recall you stating parse-partial-sexp is also unusually slow 
in that major mode, for some reason).

Here, I'm seeing some similar behavior with elisp-mode.el. I can open 
this file, evaluate

(benchmark 1000 '(syntax-ppss))

at line 10, then move to line 70 and do it there, and see the latter 
result to be much faster. They're still below 100ms usually (even with 
1000 repetitions), so that's hardly a good example of a performance 
problem, by itself.

P.S. Please send a text email next time, we very much prefer them for 
various reasons, inability to sneak in a tracker like this among them:

<img 
src=3D=22h=ttp://pixels.canarymail.io/tracking/07C7B5E0-9441-40AD-9CC3-D2A176741827.=png=22 
id=3D=22141121424AC1=466A74CBB8A45B347C37B=22 style=3D=22width: 1p=x; 
height: 1px;=22>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.