From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: [RFC]: replace-region-contents Date: Wed, 06 Feb 2019 18:02:34 +0100 Message-ID: <87h8dgetp1.fsf@gnu.org> References: <871s4rqk7u.fsf@gnu.org> <87o97syvno.fsf@gnu.org> <878syubwv3.fsf@gnu.org> <87y36u9xqt.fsf@gnu.org> <83k1ietcox.fsf@gnu.org> <87k1iew3u6.fsf@gnu.org> <83va1wsy95.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="46911"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 06 18:14:34 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1grQmQ-000C1l-Ck for ged-emacs-devel@m.gmane.org; Wed, 06 Feb 2019 18:14:34 +0100 Original-Received: from localhost ([127.0.0.1]:54269 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grQmP-0000OW-6d for ged-emacs-devel@m.gmane.org; Wed, 06 Feb 2019 12:14:33 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grQkx-0000Eo-1O for emacs-devel@gnu.org; Wed, 06 Feb 2019 12:13:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grQb2-0007jE-O9; Wed, 06 Feb 2019 12:02:48 -0500 Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:53665) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1grQat-0002Dh-Kc; Wed, 06 Feb 2019 12:02:41 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 5A5DB211B7; Wed, 6 Feb 2019 12:02:38 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 06 Feb 2019 12:02:38 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeekgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhfffgjkf gfgggtsehttdertddtredtnecuhfhrohhmpefvrghsshhilhhoucfjohhrnhcuoehtshgu hhesghhnuhdrohhrgheqnecuffhomhgrihhnpehjshhonhdqghgvnhgvrhgrthhorhdrtg homhdpghhoohhglhgvrdgtohhmnecukfhppeelfedrvdefiedruddvledrhedvnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhorhhnodhmvghsmhhtphgruhhthhhpvghrshhonh grlhhithihqdekieejfeekjeekgedqieefhedvleekqdhtshguhheppehgnhhurdhorhhg sehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Original-Received: from thinkpad-t440p (p5dec8134.dip0.t-ipconnect.de [93.236.129.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 6CB31E409D; Wed, 6 Feb 2019 12:02:36 -0500 (EST) In-Reply-To: <83va1wsy95.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 06 Feb 2019 18:00:22 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:233054 Archived-At: Eli Zaretskii writes: >> I prepared a tar.xz with a synthetic, huge, one-line JSON file >> generated by https://next.json-generator.com and a lisp file >> benchmarking the current against my proposed version of >> `json-pretty-print'. >> >> https://drive.google.com/open?id=1kKahq3csBVXWL-nN1-eMhgDctGWBN1AR > > Ouch! > > I guess we'd need to limit use of replace-region-contents to small > enough JSON strings? I wouldn't want to do that check everywhere I might want to use replace-buffer-contents. And the size is not really what matters. Instead the number of differences is the crucial thing. When I run my version on the already formatted JSON, i.e., there are zero differences, it is done exactly as fast as the original version. The bottleneck is `compareseq' in lib/diffseq.h. Maybe that could signal if more than some maximum number of differences have already been found, and in that case `replace-buffer-contents' would fallback to a plain delete and insert? Bye, Tassilo