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 19:07:38 +0100 Message-ID: <87lg2saiz9.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> <87h8dgetp1.fsf@gnu.org> <83mun8styg.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="59308"; 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 , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 06 19:08:41 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 1grRcn-000FHN-71 for ged-emacs-devel@m.gmane.org; Wed, 06 Feb 2019 19:08:41 +0100 Original-Received: from localhost ([127.0.0.1]:56533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grRcm-0007cZ-6x for ged-emacs-devel@m.gmane.org; Wed, 06 Feb 2019 13:08:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grRcC-0007c0-14 for emacs-devel@gnu.org; Wed, 06 Feb 2019 13:08:04 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grRbz-00046v-9Z; Wed, 06 Feb 2019 13:07:56 -0500 Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:46591) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1grRbp-0003WK-MF; Wed, 06 Feb 2019 13:07:41 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 0F87721DB7; Wed, 6 Feb 2019 13:07:41 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 06 Feb 2019 13:07:41 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeekgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufhffjg fkfgggtgesthdtredttdertdenucfhrhhomhepvfgrshhsihhlohcujfhorhhnuceothhs ughhsehgnhhurdhorhhgqeenucfkphepleefrddvfeeirdduvdelrdehvdenucfrrghrrg hmpehmrghilhhfrhhomhepthhhohhrnhdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqkeeijeefkeejkeegqdeifeehvdelkedqthhsughhpeepghhnuhdrohhrghesfh grshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt 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 6D6C310310; Wed, 6 Feb 2019 13:07:39 -0500 (EST) In-Reply-To: <83mun8styg.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 06 Feb 2019 19:33:11 +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:233057 Archived-At: Eli Zaretskii writes: Hi Paul, the context is `replace-buffer-contents' or rather compareseq in lib/diffseq.h being too slow when being called where the source buffer contains a huge, one-line JSON string and the replacing buffer contains the formatted version. I.e., the buffer contents are almost equal modulo gazillion of whitespace/linebreak changes. >> 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? > > There's the too_expensive member that we currently set to a very large > value; maybe we should set it lower? or provide control on it from > Lisp? I've just tried playing with that. We currently set it too one million, and then the `replace-buffer-contents' call won't finish within 30 minutes on my computer. As a base-line, the current `json-pretty-print' without `replace-buffer-contents' takes about 2 seconds. With a too_expensive value of 1000, it takes about 14 seconds with my huge, worst-case JSON file. With a value of 100 it takes about 3 seconds. With a value of 10, it segfaults. I guess there's some minimum boundary. However, I'm not really sure what the implications are. The comments say it produces suboptimal output. But what does that mean here? In the end, the formatted JSON is copied over from the replacing buffer as-is, and that's the most important thing. > Also, there's the EARLY_ABORT macro that can be defined to cause an > early return when the job is too hard. Maybe you could try defining > it to something appropriate? And fallback to plain delete & insert when it returned early? Not sure if that's better. Right now, a (much) lower value of too_expensive seems like a good option. Bye, Tassilo