From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: MPS: dangling markers Date: Thu, 27 Jun 2024 17:24:26 -0400 Message-ID: References: <87v81u85hv.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14826"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, Gerd =?windows-1252?Q?M=F6llmann?= , Eli Zaretskii , eller.helmut@gmail.com To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 27 23:25:28 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 1sMwcR-0003b5-KB for ged-emacs-devel@m.gmane-mx.org; Thu, 27 Jun 2024 23:25:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sMwbc-0003Mz-Rd; Thu, 27 Jun 2024 17:24:36 -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 1sMwba-0003Mb-Mp for emacs-devel@gnu.org; Thu, 27 Jun 2024 17:24:34 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sMwbY-0003OK-U0; Thu, 27 Jun 2024 17:24:34 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7E4FB808FB; Thu, 27 Jun 2024 17:24:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1719523467; bh=zR760CjRHHIALmwg6A0vwWWJgbHCsEf/yvZKPSX8TFo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HZn9k2vBejFy4cgdgO0DM84fspuuHkoy0317DTQQZI3vcnHYcbyA27hG94ok1hqxW rvIa060aiYaCn+6voaZDtlS9/lepMMFLBfmjQ32ngCozr8zkIk/jRZt7uNrhV4Xfjh j2pwsR95IUj6r+pL0Hgaw7MJ+VDWGCZMU2yQ/d7QJjxIZZEnp80VRunyW0pOm88pYT xqQZlglT4r+4MIkijWE37IIdvQI8ZSMhnSAMsG/GPsFm+Ozzj2Z7dASppW9QjaSqdm A2E63HcrwP5OcjFY9tNZNxzkR4phVd8sK6sw0e/gfNjPmSn4Ixey1HX7JIGGTYx2cs GwrRB7SfL/uJQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7AFDB803AD; Thu, 27 Jun 2024 17:24:27 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6714A12051B; Thu, 27 Jun 2024 17:24:27 -0400 (EDT) In-Reply-To: <87v81u85hv.fsf@localhost> (Ihor Radchenko's message of "Thu, 27 Jun 2024 21:01:32 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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: , 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:320784 Archived-At: > - perf points to (1) itree lookup; (2) bytepos<->charpos, which implies > that things may be related to the number of allocated markers and > overlays. > - I observe things slowing down as the number of "PVEC_MARKER" in the > output of `igc-info' grows. > - Forcing (igc--collect) returns speed to normal [...] > AFAIK, at least overlays, buffers, and markers are used in C code within > object lists/trees are often traversed in full. If objects in these > lists are not regularly garbage-collected, we may end up in situation > when dead objects significantly impact performance. AFAIK, markers are the only one that can be reachable (i.e. we may spend time looking at them) yet GC-able, because the buffers' `markers` slot contains a linked-list of all markers that's treated specially by the GC (basically, the list is "weak" so markers get removed from this list during GC if the marker is reachable only from the list). [ Of course, similar things can occur with other objects via our weak hash table. And there are a few other "background cleanups" we do in GC (such as resizing gaps or truncating undo logs) which could be impacted as well. ] So I'm not surprised by your point (2) above, but I don't have an explanation for your point (1), OTOH. BTW, a lof of C and ELisp code is careful to delete markers after their use, so I suspect that a large proportion of the "dead" markers that can accumulate in the list of markers are those created by the chars<->bytes conversion code (as a memoization cache), and we should be able to decouple their collection from the GC by simply adding a bit that says this is just a cached result of a previous chars<->bytes conversion, rather than a true marker object, and then we could have a "background task" that flushes them as needed. Stefan