From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 20154@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 [thread overview]
Message-ID: <550DE1FB.2060409@yandex.ru> (raw)
In-Reply-To: <83zj76rtbn.fsf@gnu.org>
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.
next prev parent reply other threads:[~2015-03-21 21:26 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 14:26 bug#20154: 25.0.50; json-encode-string is too slow for large strings Dmitry Gutov
2015-03-20 14:34 ` Eli Zaretskii
2015-03-20 14:43 ` Dmitry Gutov
2015-03-20 15:03 ` Eli Zaretskii
2015-03-20 15:20 ` Dmitry Gutov
2015-03-20 16:02 ` Eli Zaretskii
2015-03-20 16:21 ` Dmitry Gutov
2015-03-20 16:44 ` Eli Zaretskii
2015-03-20 16:52 ` Dmitry Gutov
2015-03-20 17:44 ` Eli Zaretskii
2015-03-20 18:42 ` Dmitry Gutov
2015-03-20 21:14 ` Eli Zaretskii
2015-03-20 22:02 ` Dmitry Gutov
2015-03-21 7:58 ` Eli Zaretskii
2015-03-21 8:12 ` Eli Zaretskii
2015-03-21 20:00 ` Dmitry Gutov
2015-03-21 20:25 ` Eli Zaretskii
2015-03-21 21:26 ` Dmitry Gutov [this message]
2015-03-22 17:31 ` Eli Zaretskii
2015-03-22 18:13 ` Dmitry Gutov
2015-03-22 18:26 ` Dmitry Gutov
2015-03-22 18:32 ` Eli Zaretskii
2015-03-22 19:03 ` Dmitry Gutov
2015-03-21 21:05 ` Drew Adams
2015-03-21 21:32 ` Dmitry Gutov
2015-04-20 22:20 ` Ted Zlatanov
2015-04-20 22:41 ` Dmitry Gutov
2015-04-20 23:11 ` Ted Zlatanov
2015-03-20 22:26 ` Dmitry Gutov
2015-03-21 8:07 ` Eli Zaretskii
2015-03-21 21:09 ` Dmitry Gutov
2015-03-21 22:20 ` Ivan Shmakov
2015-03-21 23:36 ` Dmitry Gutov
2015-03-22 14:52 ` Dmitry Gutov
2015-03-22 16:15 ` Ivan Shmakov
2015-03-22 16:47 ` Dmitry Gutov
2015-03-22 17:43 ` Eli Zaretskii
2015-03-22 19:15 ` Ivan Shmakov
2015-03-22 16:51 ` Eli Zaretskii
2015-03-22 18:22 ` Glenn Morris
2015-03-22 16:50 ` Eli Zaretskii
2015-03-22 17:10 ` Dmitry Gutov
2015-03-22 22:57 ` Dmitry Gutov
2015-03-23 15:37 ` Eli Zaretskii
2015-04-07 13:31 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=550DE1FB.2060409@yandex.ru \
--to=dgutov@yandex.ru \
--cc=20154@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).