From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Sebastian Sturm Newsgroups: gmane.emacs.devel Subject: Re: State of the overlay tree branch? Date: Fri, 23 Mar 2018 13:25:19 +0100 Message-ID: <1ea4248a-11ce-00a9-0644-df7b2e5a3a58@arkona-technologies.de> References: <834lldp18f.fsf@gnu.org> <9646341d-700b-4240-216b-8c0e753fa79f@arkona-technologies.de> <86d03e78-9984-f33e-a3f3-3faa4b34d78b@arkona-technologies.de> <83vadso9ad.fsf@gnu.org> <5155d5e2-6b5c-581e-89fe-4f3af717304f@arkona-technologies.de> <4c82fcbd-961a-c6ca-b1f0-6b85665cb339@arkona-technologies.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1521807869 8193 195.159.176.226 (23 Mar 2018 12:24:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2018 12:24:29 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 13:24:25 2018 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 1ezLk8-000230-I2 for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 13:24:24 +0100 Original-Received: from localhost ([::1]:37753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezLmB-0005kB-JS for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 08:26:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezLl7-0005i2-NO for emacs-devel@gnu.org; Fri, 23 Mar 2018 08:25:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ezLl3-0002AH-DM for emacs-devel@gnu.org; Fri, 23 Mar 2018 08:25:25 -0400 Original-Received: from smtp-out003.kontent.com ([81.88.40.217]:46408) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ezLl2-00028b-Po for emacs-devel@gnu.org; Fri, 23 Mar 2018 08:25:21 -0400 Original-Received: from [172.16.222.49] (unknown [213.157.6.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: arkona-technologies_de_22@smtp-out003.kontent.com) by smtp-out003.kontent.com (Postfix) with ESMTPSA id 584004001D07 for ; Fri, 23 Mar 2018 13:25:19 +0100 (CET) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 81.88.40.217 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:223957 Archived-At: I haven't tested this very extensively yet, but artificial benchmark=20 results are now comparable to the noverlay branch and editing seems=20 similarly fluid. Many thanks for that! On a tangential note, removing the bottleneck now brought up another=20 hotspot in my performance profile (less severe than the one previously=20 reported) that seems to be due to cc-mode itself. Since I don't want to=20 derail this thread, I'll try to implement some of the suggestions made=20 in the "Latency profiling?" thread and come up with some reproducible=20 data on that other issue. On 03/23/2018 06:03 AM, Stefan Monnier wrote: >> since noverlay performs so well, I guess the technical issue here is a= lready >> solved and I'll just have to wait for it to make it into the master >> branch. >=20 > Yes and no: there can still be many markers (even without having any > overlays) and that poses the same problem (and the noverlays branch > doesn't change that). >=20 > I've made some further tests and found that the patch I sent indeed > doesn't help tremendously with "distance +=3D 10" but that when we reac= h > "+=3D 50" the effect is more significant. >=20 > Could you try the patch below (ideally not just with artificial tests > but also in actual use) to see if it helps? >=20 >=20 > Stefan >=20 >=20 > diff --git a/src/marker.c b/src/marker.c > index 7773c4fce0..6ab0d3d61e 100644 > --- a/src/marker.c > +++ b/src/marker.c > @@ -133,6 +133,28 @@ CHECK_MARKER (Lisp_Object x) > CHECK_TYPE (MARKERP (x), Qmarkerp, x); > } > =20 > +/* When converting bytes from/to chars, we look through the list of > + markers to try and find a good starting point (since markers keep > + track of both bytepos and charpos at the same time). > + But if there are many markers, it can take too much time to find a = "good" > + marker from which to start. Worse yet: if it takes a long time and= we end > + up finding a nearby markers, we won't add a new marker to cache thi= s > + result, so next time around we'll have to go through this same long= list > + to (re)find this best marker. So the further down the list of > + markers we go, the less demanding we are w.r.t what is a good marke= r. > + > + The previous code used INITIAL=3D50 and INCREMENT=3D0 and this lead= to > + really poor performance when there are many markers. > + I haven't tried to tweak INITIAL, but my experiments on my trusty T= hinkpad > + T61 using various artificial test cases seem to suggest that INCREM= ENT=3D50 > + might be "the best compromise": it significantly improved the > + worst case and it was rarely slower and never by much. > + > + The asymptotic behavior is still poor, tho, so in largish buffers w= ith many > + overlays (e.g. 300KB and 30K overlays), it can still be a bottlneck= . */ > +#define BYTECHAR_DISTANCE_INITIAL 50 > +#define BYTECHAR_DISTANCE_INCREMENT 50 > + > /* Return the byte position corresponding to CHARPOS in B. */ > =20 > ptrdiff_t > @@ -141,6 +163,7 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t= charpos) > struct Lisp_Marker *tail; > ptrdiff_t best_above, best_above_byte; > ptrdiff_t best_below, best_below_byte; > + ptrdiff_t distance =3D BYTECHAR_DISTANCE_INITIAL; > =20 > eassert (BUF_BEG (b) <=3D charpos && charpos <=3D BUF_Z (b)); > =20 > @@ -180,8 +203,10 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_= t charpos) > /* If we are down to a range of 50 chars, > don't bother checking any other markers; > scan the intervening chars directly now. */ > - if (best_above - best_below < 50) > + if (best_above - best_below < distance) > break; > + else > + distance +=3D BYTECHAR_DISTANCE_INCREMENT; > } > =20 > /* We get here if we did not exactly hit one of the known places. > @@ -293,6 +318,7 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t= bytepos) > struct Lisp_Marker *tail; > ptrdiff_t best_above, best_above_byte; > ptrdiff_t best_below, best_below_byte; > + ptrdiff_t distance =3D BYTECHAR_DISTANCE_INITIAL; > =20 > eassert (BUF_BEG_BYTE (b) <=3D bytepos && bytepos <=3D BUF_Z_BYTE (= b)); > =20 > @@ -323,8 +349,10 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_= t bytepos) > /* If we are down to a range of 50 chars, > don't bother checking any other markers; > scan the intervening chars directly now. */ > - if (best_above - best_below < 50) > + if (best_above - best_below < distance) > break; > + else > + distance +=3D BYTECHAR_DISTANCE_INCREMENT; > } > =20 > /* We get here if we did not exactly hit one of the known places. >=20 >=20 --=20 Sebastian Sturm Research & Development Phone: +49 (0) 6155 7808977 Fax: +49 (0) 6155 7802880 Email: s.sturm@arkona-technologies.de Web: www.arkona-technologies.de arkona technologies GmbH Im Leuschnerpark 4 64347 Griesheim Germany Amtsgericht / Commercial Register of Darmstadt, HRB 90080 USt-ID: DE273794666 Steuernummer / Tax-ID: 007 / 228 / 19331 Gesch=C3=A4ftsf=C3=BChrung / Managing Director: Rainer Sturm This e-mail may contain confidential and/or privileged information. If=20 you are not the intended recipient (or have received this e-mail in=20 error) please notify the sender immediately and delete this message and=20 any attachments from your system. Any unauthorised copying, disclosure=20 or distribution of the material in this e-mail is strictly forbidden. We cannot accept any responsibility for the accuracy or completeness of=20 this message as it has been transmitted over a public network. If,=20 despite our use of anti-virus software, a virus enters your systems in=20 connection with the sending of the e-mail, you may not hold us liable=20 for any damages that may possibly arise in that connection. We will=20 accept liability which by law we cannot exclude.