GNU bug report logs - #20154
25.0.50; json-encode-string is too slow for large strings

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20154 <at> debbugs.gnu.org
Subject: bug#20154: 25.0.50; json-encode-string is too slow for large strings
Date: Sat, 21 Mar 2015 23:26:19 +0200

On 03/21/2015 10:25 PM, Eli Zaretskii wrote:

> So each keypress you need to encode the whole buffer, including the
> last keypress and all those before it?

Pretty much. Ycmd server uses caching heavily, so it's not bothered by 
the frequent requests. And when extracting it from the YCM Vim package, 
the author measured the transport overhead, saw it's negligible, and 
went with the "send everything" approach. Here's the blog post about it:

https://plus.google.com/+StrahinjaMarković/posts/Zmr5uf2jCHm

(He's saying there the json module used is pure Python; this part he's 
most likely mistaken about).

> I guess I don't really understand why each keypress should trigger
> encoding of the whole buffer.

It's not necessary, just the recommended workflow. The server can take 
it: 
https://github.com/company-mode/company-mode/issues/325#issuecomment-83154084, 
and this way the suggestions reach the user the soonest.

Or course, we can wait until Emacs is idle for a bit, but even so if 
encoding takes 100ms (never mind 500ms it takes now), that can create 
visible stutters where they don't have to be, if the user starts typing 
again in the middle of it.

>> (replace-regexp-in-string "x" "z" s1 t t)
>>
>> - only takes ~3ms.
>
> Then a series of calls to replace-regexp-in-string, one each for every
> one of the "special" characters, should get you close to your goal,
> right?

No no no. There are no "x" characters in s1. I just wanted to 
demonstrate that the regexp searching by itself is not a bottleneck, so 
`skip-chars-forward' isn't really warranted. As long as we're replacing 
an actual character present in the string, it takes well above 3ms.

>> And likewise, after changing them to use `concat' instead of `format',
>> both alternative json-encode-string implementations that I have "encode"
>> a numbers-only (without newlines) string of the same length in a few
>> milliseconds. Again, save for the GC pauses, which can add 30-40ms.
>
> So does this mean you have your solution?

No. An actual buffer has lots of newlines, which need to be encoded. 
Again, the above is about the speed of the regexp engine.

Previous Next

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