From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: noverlay branch Date: Mon, 24 Oct 2022 09:21:13 -0700 Message-ID: <87o7u18a6e.fsf@rfc20.org> References: <875ygb401m.fsf@rfc20.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33167"; mail-complaints-to="usenet@ciao.gmane.io" To: Stefan Kangas , Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 24 19:02:07 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1on0pz-0008RW-4W for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Oct 2022 19:02:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1on0Cd-00042y-5M; Mon, 24 Oct 2022 12:21:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1on0Cb-00042o-PZ for emacs-devel@gnu.org; Mon, 24 Oct 2022 12:21:25 -0400 Original-Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1on0CX-0001JL-Mw for emacs-devel@gnu.org; Mon, 24 Oct 2022 12:21:24 -0400 Original-Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id 2489F240008; Mon, 24 Oct 2022 16:21:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1666628477; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bUcR2Uda8Ny+grxnIHeFA5eTMnSnlptI6iCTvOhkDWo=; b=GVp7BSp8OqLsduszf7ZHTlOVPb1NJbPL/o7T2tGVd0IRNWvOySgCXoicCHxqSI+3ixfo0e EU0CBZbybQQRCZgLwc3jj/YbX9nmdAd0J6m6fUWgaVFmX/DnCANKjHDQ51ZlpNzEhyROI6 sGNb8GgcLRQTZkX9GnM8u+luu0ZXLb47hBpBwnCM5AZ1ODvgRi2VP5XOWR0idXeSlRcj42 x4mCUFowRt1nLn2P5y/kHQUK+BKI9YMMCP9zLgLA+puiP9u4qFYrFrIWZk7d/+OoM1e0hp 8PSV7EnhStsKKNId0MP0hRwAOyv0pgcfPxU5y2KKaaVlAijYQgILZac9WlMF0g== Original-Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1on0CP-0002CH-1K; Mon, 24 Oct 2022 09:21:13 -0700 In-Reply-To: Received-SPF: pass client-ip=217.70.183.193; envelope-from=matt@rfc20.org; helo=relay1-d.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298390 Archived-At: Stefan Kangas writes: > Matt Armstrong writes: > >> TLDR: things are looking pretty stable and good on the feature/noverlay >> branch. If anyone here tested it a month ago and found it lacking, give >> it another whirl. > > Would it be welcome to merge master into that feature branch? I'm leaving the merge decision up to Stefan and other committers. I'm happy to accept commit privs and help out with this, but I'm still pretty green. There are two things I think should be done before a merge: 1) Relax some of the 'echeck' calls in src/itree.c. They are too expensive and actually make --enable-checking builds much slower than they are on 'master' when there are non-trivial numbers of overlays. Stefan has added FIXME comments for most of these. 2) Run some benchmarks. My preliminary results seem to show that Emacs redisplay can be marginally slower when the overlay count is low (with what we'd consider "acceptable numbers" of overlays today), but much faster when things get out of hand. 3) Anything Stefan has in his head. :) > BTW, I can see two warnings, with gcc 12.2.0: > > In function =E2=80=98interval_tree_remove_fix=E2=80=99, > inlined from =E2=80=98itree_remove=E2=80=99 at itree.c:1110:5: > itree.c:923:15: warning: potential null pointer dereference [-Wnull-deref= erence] > 923 | if (null_safe_is_black (other->left) /* 2.a */ > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > itree.c:960:15: warning: potential null pointer dereference [-Wnull-deref= erence] > 960 | if (null_safe_is_black (other->right) /* 2.b */ > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Those warnings are false positives, though the invariant relies on red-black in variants and is too complex for a compiler to realize. Heck, I have to sit down and draw things out to re-prove it to myself every time. https://git.sr.ht/~matta/emacs/log/scratch/matta/for_stefan has a patch for it (which uses 'eassume'), or we could just check for NULL even though it should never happen. > I'm now running feature/noverlay here (with master merged locally), > and will report back if I run into any issues. I'd welcome a merge from master on feature/noverlay. I think it has been one month.