From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20154: 25.0.50; json-encode-string is too slow for large strings Date: Sun, 22 Mar 2015 19:31:24 +0200 Message-ID: <83r3shrlar.fsf@gnu.org> References: <86twxf68zk.fsf@yandex.ru> <83384zwxdx.fsf@gnu.org> <550C3218.4000903@yandex.ru> <831tkjww0y.fsf@gnu.org> <550C3AB9.7020403@yandex.ru> <83wq2bveq6.fsf@gnu.org> <550C491A.6000909@yandex.ru> <83siczvcss.fsf@gnu.org> <550C504A.10708@yandex.ru> <83r3sjva0q.fsf@gnu.org> <550C6A06.6040203@yandex.ru> <83fv8zv0b1.fsf@gnu.org> <550C990B.8080505@yandex.ru> <838ueqvl1o.fsf@gnu.org> <550DCDEE.4090900@yandex.ru> <83zj76rtbn.fsf@gnu.org> <550DE1FB.2060409@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1427045548 9310 80.91.229.3 (22 Mar 2015 17:32:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Mar 2015 17:32:28 +0000 (UTC) Cc: 20154@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 22 18:32:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YZjjT-0006is-Sf for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Mar 2015 18:32:16 +0100 Original-Received: from localhost ([::1]:51776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZjjT-0001lo-0X for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Mar 2015 13:32:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZjjK-0001jz-Um for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 13:32:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZjjG-0006BV-3U for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 13:32:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZjjG-0006BL-1G for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 13:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZjjF-000583-Mg for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 13:32:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Mar 2015 17:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20154 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20154-submit@debbugs.gnu.org id=B20154.142704550919698 (code B ref 20154); Sun, 22 Mar 2015 17:32:01 +0000 Original-Received: (at 20154) by debbugs.gnu.org; 22 Mar 2015 17:31:49 +0000 Original-Received: from localhost ([127.0.0.1]:60859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZjj3-00057d-8M for submit@debbugs.gnu.org; Sun, 22 Mar 2015 13:31:49 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:56711) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZjj0-00057N-Tz for 20154@debbugs.gnu.org; Sun, 22 Mar 2015 13:31:47 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NLM00700JBB2C00@a-mtaout21.012.net.il> for 20154@debbugs.gnu.org; Sun, 22 Mar 2015 19:31:40 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLM007YUJCS1A10@a-mtaout21.012.net.il>; Sun, 22 Mar 2015 19:31:40 +0200 (IST) In-reply-to: <550DE1FB.2060409@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:100792 Archived-At: > Date: Sat, 21 Mar 2015 23:26:19 +0200 > From: Dmitry Gutov > CC: 20154@debbugs.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. I understand why you _send_ everything, but not why you need to _encode_ everything. Why not encode only the new stuff? > >> (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 know. I meant something like (replace-regexp-in-string "\n" "\\n" s1 t t) (replace-regexp-in-string "\f" "\\f" s1 t t) etc. After all, the list of characters to be encoded is not very long, is it? > > 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. But when you've encoded them once, you only need to encode the additions, no? If you can do this incrementally, the amount of work for each keystroke will be much smaller, I think.