From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: dangling markers Date: Sun, 30 Jun 2024 08:11:33 +0300 Message-ID: <861q4fhv5m.fsf@gnu.org> References: <87v81u85hv.fsf@localhost> <87frsx81m2.fsf@localhost> <87cyo180y2.fsf@localhost> <874j9d7zqe.fsf@localhost> <87sewvg6lw.fsf@localhost> <86ed8fiug3.fsf@gnu.org> <86bk3jirx7.fsf@gnu.org> <868qynipph.fsf@gnu.org> <87wmm75xze.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19234"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org, eller.helmut@gmail.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 30 07:11:55 2024 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 1sNmqw-0004hZ-8s for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 07:11:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNmqg-0001NJ-6E; Sun, 30 Jun 2024 01:11:38 -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 1sNmqe-0001M6-2H for emacs-devel@gnu.org; Sun, 30 Jun 2024 01:11:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sNmqd-0000Ui-ES; Sun, 30 Jun 2024 01:11:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=63NBtMsmKU4Ukfo8pqI4GAr5yT+reHaRqSfNrgaqbec=; b=p3vYnGG6i4Q2 h9mMJKfFgVfbo+VKZHvcT4i5P76KBICBMDM1JPS8f8D8+aWHjAcHmzC4oYkcncdLqF4PhLpG0hDy2 qQEMFkH1SsctWs8hoiNS7oRvZbJCjFK0iAwVd3RPMpMnrkmP2aLVWdDVyFmxhjFcscgCtzvQVU4o7 5qcaTpHz0epNE+vL0Ufx2geBRH4yyrBlktp1WBqiwyBxrWPBRaLQ9JsEQhUY9C8RRvhwxJicfexym OjJgbfiHcI/gffMv6DVzdL2TFq+ivkQ0SmMVD2Zsf6FFyC24rIcODVDslNiJ973LjNfVs546lkXes bIPcTd4OqiH0jdCXEfPOmw==; In-Reply-To: (message from Stefan Monnier on Sat, 29 Jun 2024 18:59:15 -0400) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:320912 Archived-At: > From: Stefan Monnier > Cc: Ihor Radchenko , Eli Zaretskii , > emacs-devel@gnu.org, eller.helmut@gmail.com > Date: Sat, 29 Jun 2024 18:59:15 -0400 > > > Jup, it's point-marker for me. No idea who calls that so often. > > I think the core of the problem, then, is that currently it's completely > normal to rely on the GC to "remove" markers we don't care about any > more instead of explicitly removing them when we don't need them any > more (with `move-marker`). > > So if the GC takes a long time to call `unchain_dead_markers`, we end up > with a very large set of markers and it's not clear how to handle that > efficiently. > > I understand that relying on a prompt collection of dead objects is > a bad idea, but we may have to try and make sure it's prompt enough > because of the legacy of code which relies on it when it comes > to markers. > > If not, we'll have to work at a better data-structure able to handle > a large set of markers. The `itree` would probably be our best best but > if we end up with many markers at the very same place (which seems > likely if we often call `point-marker`), we'll hit its worst case (where > it goes back to O(N) tho this N is only the number of markers at a given > position rather than the total number of markers). > > [ Another option might be to have a kind of two-level set of markers, > where we keep the "recently used" markers in one data structure > (optimized for adding/removing/moving/gettingtheposition) and then we > demote markers that have not been recently used to a secondary > data-structure optimized for "low-cost long term maintenance", kind of > a like an archive of markers which are predicted to be dead. ] > > [ BTW, for the bytes<->chars conversion, we could also use a plain array > indexed by CHARPOS/CHUNKSIZE where instead of updating the entries > upon text insertion/deletion we just truncate the array to the last > still-valid entry before the point of insertion/deletion. ] All good idea, but I think they should take a back seat for now. We still have unresolved issues that cause crashes, like the one with SIGPROF and SIGCHLD happening at the wrong time. We should prioritize solving those first. Because a slower Emacs will still be usable (especially if the slow-down happens only in some specific modes), whereas an Emacs which crashes is not. Let's not get distracted by issues that have secondary importance at this stage.