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: Sun, 22 Mar 2015 20:13:30 +0200 Message-ID: <550F064A.5030909@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> <550DE1FB.2060409@yandex.ru> <83r3shrlar.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: 7bit X-Trace: ger.gmane.org 1427048069 15943 80.91.229.3 (22 Mar 2015 18:14:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Mar 2015 18:14:29 +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 Sun Mar 22 19:14:18 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 1YZkO8-0004dq-7O for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Mar 2015 19:14:16 +0100 Original-Received: from localhost ([::1]:52006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZkO2-00048f-Fx for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Mar 2015 14:14:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZkNy-00048L-4z for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 14:14:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZkNt-0001Bx-Ts for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 14:14:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZkNt-0001Bt-R8 for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 14:14:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZkNt-0006Eg-LH for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 14:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Mar 2015 18:14: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.142704802223931 (code B ref 20154); Sun, 22 Mar 2015 18:14:01 +0000 Original-Received: (at 20154) by debbugs.gnu.org; 22 Mar 2015 18:13:42 +0000 Original-Received: from localhost ([127.0.0.1]:60899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZkNa-0006Dt-6j for submit@debbugs.gnu.org; Sun, 22 Mar 2015 14:13:42 -0400 Original-Received: from mail-we0-f181.google.com ([74.125.82.181]:36822) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZkNX-0006DQ-RN for 20154@debbugs.gnu.org; Sun, 22 Mar 2015 14:13:40 -0400 Original-Received: by wetk59 with SMTP id k59so120974283wet.3 for <20154@debbugs.gnu.org>; Sun, 22 Mar 2015 11:13:34 -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=3/lAJSeN/EJbG5Ejl8dit5vMwv2VqcJr4tmBczTdVP0=; b=Er4PdWayjE6nWy+K+jnnIxS/IOJLDqQ9b79jVci638HdT1epQ0klFIxnDrTmV5uC5R 8XQhjT/5NhKkZ7QeGEgrEs531lIgHfAmuNvw+If+Qe+5AMKs8JyXvKcJ2xYHetvnvPRK GFO2rieGwvyKGJcv/14rWFMMDVk8KQOqneCxajgxJ1WHZMWVRsaLbWTlEh0prDT+0z03 6LDvT2tkBcTqkqrXxU6Tmc9zmycCsQ5MF+I+93uw4j8+BWiT+SlMkWMTg6mTdkXN3+Q2 iWG+o8czW2oY7GIWBqQl0jKfoRGy3WhJrJTuZb/2KJk8Vl9BNz2oYaz4BcyN92sSdENt J0Mg== X-Received: by 10.194.48.12 with SMTP id h12mr183104177wjn.74.1427048014302; Sun, 22 Mar 2015 11:13:34 -0700 (PDT) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id k4sm4734418wiz.0.2015.03.22.11.13.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2015 11:13:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <83r3shrlar.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:100799 Archived-At: On 03/22/2015 07:31 PM, Eli Zaretskii wrote: > I understand why you _send_ everything, but not why you need to > _encode_ everything. Why not encode only the new stuff? That's the protocol. You're welcome to bring the question up with the author, but for now, as already described, there has been no need to complicate it, because Vim compiled with Python support can encode even a large buffer quickly enough. >>> 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? Actually, that wouldn't work anyway: aside from the special characters, JSON \\u1234 needs to encode any non-ASCII characters. Look at the "Fallback: UCS code point" comment. > 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? One (replace-regexp-in-string "\n" "\\n" s1 t t) call already takes ~100ms, which is more than the latest proposed json-encode-string implementation takes. > 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. Sure, that's optimizable, with a sufficiently smart server (which ycmd currently isn't), and at the cost of some buffer state tracking and diffing logic.