From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: String encoding in json.c Date: Sat, 23 Dec 2017 16:43:30 +0200 Message-ID: <83tvwhjyi5.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1514040149 2911 195.159.176.226 (23 Dec 2017 14:42:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Dec 2017 14:42:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 23 15:42:24 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eSl0K-0000PZ-Np for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 15:42:24 +0100 Original-Received: from localhost ([::1]:42206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSl2J-0003Za-9o for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 09:44:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSl1Q-0003YG-C9 for emacs-devel@gnu.org; Sat, 23 Dec 2017 09:43:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSl1N-0004VO-5n for emacs-devel@gnu.org; Sat, 23 Dec 2017 09:43:32 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSl1N-0004VK-1s; Sat, 23 Dec 2017 09:43:29 -0500 Original-Received: from [176.228.60.248] (port=4010 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eSl1M-00053o-G9; Sat, 23 Dec 2017 09:43:28 -0500 In-reply-to: (message from Philipp Stephani on Sat, 23 Dec 2017 14:26:09 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221374 Archived-At: > From: Philipp Stephani > Date: Sat, 23 Dec 2017 14:26:09 +0000 > > I've benchmarked serialization and parsing of JSON with and without explicit encoding. I've found that leaving > out the coding makes both operations significantly faster – from a speedup of a factor of 1.11 ± 0.06 for > parsing canada.json to 1.57 ± 0.08 for serializing twitter.json. Other speedups are in between, but the > speedup is always significant (to at least one standard deviation). All unit tests pass when leaving out the > coding steps – which isn't surprising given that currently the coding operations are expensive no-ops. The coding operations are "expensive no-ops" except when they aren't, and that is exactly when we need their 'expensive" parts. > Therefore I'd suggest to document the internal string encoding in lisp.h or character.h and remove the explicit > coding in json.c and emacs-module.c. It's very unlikely that the internal string encoding will change frequently, > and if so, the unit tests should catch potential issues caused by that. As I've already said, I don't think this particular case should be an exception wrt to how Emacs behaves with external strings everywhere else. We suffer similar slow-downs in those other places as well, and IMO this is a small penalty to pay for making sure our objects are valid and won't crash Emacs. The main purpose of Emacs is to be an efficient editor, so if we care about the slow-down of code conversions, we should first and foremost speed up reading and writing files. JSON conversion, with all due respect to them, are not the main business for us, and I'm not even sure JSON objects will frequently be as large as files our users visit all the time.