From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#20154: 25.0.50; json-encode-string is too slow for large strings Date: Sat, 21 Mar 2015 23:26:19 +0200 Message-ID: <550DE1FB.2060409@yandex.ru> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1426973244 19280 80.91.229.3 (21 Mar 2015 21:27:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 21:27:24 +0000 (UTC) Cc: 20154@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 21 22:27:15 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 1YZQvG-0000no-Pv for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 22:27:11 +0100 Original-Received: from localhost ([::1]:49039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZQvF-00034x-O3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 17:27:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZQvC-00034G-0O for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 17:27:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZQv8-0001Xi-OR for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 17:27:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42100) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZQv8-0001Xc-LW for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 17:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZQv7-0000pd-VZ for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 17:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Mar 2015 21:27: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.14269731913159 (code B ref 20154); Sat, 21 Mar 2015 21:27:01 +0000 Original-Received: (at 20154) by debbugs.gnu.org; 21 Mar 2015 21:26:31 +0000 Original-Received: from localhost ([127.0.0.1]:60109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZQuc-0000os-Bl for submit@debbugs.gnu.org; Sat, 21 Mar 2015 17:26:30 -0400 Original-Received: from mail-wi0-f176.google.com ([209.85.212.176]:36539) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZQua-0000of-3t for 20154@debbugs.gnu.org; Sat, 21 Mar 2015 17:26:28 -0400 Original-Received: by wibg7 with SMTP id g7so15932887wib.1 for <20154@debbugs.gnu.org>; Sat, 21 Mar 2015 14:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WL++uxWQ4ZmvkDuj/GwXARDGUkllgp4vpRMrOOXSJg4=; b=W6MlUfFDOvi0IHiAZ047SvSX8rF3o/4gTaVNIRIRrMmbNLd1boMDgavdNcY9RnVj/l x57gGuySxV/5N0yn8n8yc3AzXBg5Um7/iP2/e+EtbryxbRNDNHiX5YAH0tadxIETB0u+ YXSyb2bWRIxirWDBsqlUFawJyW3aCQjdfNVEERu1/MLK+TEh7tgTd9/7+3PJxpnd9iAg wwaVqlLOqu+JZoa2YC4R+Szz4Pgu8RcIL4g4/HeD3EcY+e/DmHJGymymzX0ATuMb+/U2 +3XlfqDNKQb+LY6MuzlFBmdEhFvDll4djnPI1I9/a+qUA3L5aIuQlZMAjHlu7/UWZy2g wjJA== X-Received: by 10.194.62.167 with SMTP id z7mr174065781wjr.106.1426973182428; Sat, 21 Mar 2015 14:26:22 -0700 (PDT) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id gd6sm3987639wib.17.2015.03.21.14.26.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2015 14:26:21 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <83zj76rtbn.fsf@gnu.org> 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:100763 Archived-At: 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.