From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Mon, 16 Aug 2021 14:49:45 +0200 Message-ID: References: <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="992"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru, larsi@gnus.org, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 14:50:16 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mFc4F-000AVs-P0 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 14:50:15 +0200 Original-Received: from localhost ([::1]:47332 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFc4E-00021M-EI for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 08:50:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFc44-0001zg-Cv for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:50:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37354) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFc42-0002ku-BK for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:50:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFc42-0002Bb-9W for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291181968379 (code B ref 48841); Mon, 16 Aug 2021 12:50:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:49:56 +0000 Original-Received: from localhost ([127.0.0.1]:48899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFc3w-0002B0-7m for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:49:56 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:59823 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFc3u-0002Af-FE; Mon, 16 Aug 2021 08:49:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=kZrT7LuVRK9XGgsyWGpuxLP8FMvP7eeoAoRJa1adfP8=; b=BH6TKB+fVaN/xvMTztdySZbl+R ICbPRP+GFV1yS4R2oqMVSOGN5kRp6rCsBT2bq3J/+7c9HG0cOZoCV5nGxnAbDenMkZDpZhnpX36Vg axzIfoOp3ByTbm/Tw1zZrSyLjmDosJbk1jC0bANXga0bAhGgMq341ZOM0He1EeQvUBmc=; In-Reply-To: <83k0kl8sxm.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:212008 Archived-At: On 8/16/21 2:39 PM, Eli Zaretskii wrote: >> João, I am giving hard examples here. What is not an example about >> "memory leak" or making debugging output verbose thanks to the attached >> string properties? > > FWIW, I also don't understand how adding properties could cause a > memory leak. When a string is GCed, its properties get GCed as well, > all of them. Am I missing something? If you add string properties to all symbol names this memory will stay alive for much longer than necessary. It is not a memory leak in the strongest sense. The memory is still reachable, but there is still no need to keep the string properties allocated. This is comparable to memory leaks in other GCed languages where memory is also kept alive for longer than necessary. > As to more difficult debugging, I think adding a couple of properties > that have simple structure will not impair debugging too much. > Strings with many properties are not uncommon in Emacs, so we already > have to deal with that. I disagree with that. We are talking about adding string properties to every symbol name. This is a global side effect and different from adding string properties to a set of isolated string in a controlled manner. I also don't understand why one would even want to take any chances here given that the feature can be implemented in a way which avoids this global side effect entirely as my patch shows. >> As I said, I will ensure that my API does not introduce performance >> regressions. And since my new API performs strictly less work than your >> proposal it will necessarily be faster if you consider only the >> filtering, which is what matters for incrementally updating UIs. > > I would indeed suggest both to make sure there's no performance > regressions, and would like to see some data similar to what João > presented, which backs up your assessments about your proposal being > faster. Since performance is the main motivation for these changes, I > think it's important for us to be on the same page wrt facts related > to performance, before we make the decision how to proceed. I will prepare some benchmarks. Daniel