From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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 17:33:20 +0300 Message-ID: References: <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> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23125"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: Daniel Mendler , monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, larsi@gnus.org, 47711@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 16:34:12 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 1mFdgq-0005po-7v for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 16:34:12 +0200 Original-Received: from localhost ([::1]:33820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFdgo-00020G-S1 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 10:34:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFdgh-0001yP-8D for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 10:34:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39176) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFdgh-0004AO-1w for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 10:34:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFdgg-0005Sz-VI for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 10:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:34: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.162912441220969 (code B ref 48841); Mon, 16 Aug 2021 14:34:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:33:32 +0000 Original-Received: from localhost ([127.0.0.1]:50721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdgB-0005S3-Jo for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:33:31 -0400 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:44708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdg9-0005Rl-6Q; Mon, 16 Aug 2021 10:33:29 -0400 Original-Received: by mail-wr1-f46.google.com with SMTP id x12so23930221wrr.11; Mon, 16 Aug 2021 07:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7yhkRd6f073YFMR5goDbFsS2fzyvIVrl94x/SsJzrBg=; b=DY50Iid1Sbj2GK1mneKSFMOsR+9XsulzGyPciOTRvzyaHaUnuYgT5vGlUWgZZmI1dy 4swb/1o5E76ywfkXBcHk2Nkqv3xUJIZioPA323JMbV6uox8gW32xN7aP5VNXC+1ED2wZ SIPrO14fbQ2xB7XHHOTBO8/3yLADLP+MfXtGGj2fOSu3O5/V4gaI1hM3PIZme1+LRSE+ Lpun3UAf8nLGSjofB0sy/+NayRhvlTxnxk+NCq0YftQ0Eydd8cfsh83xSgBnUEqwLTvO 3+0HJ31QLtknj/2c+FQUKnoXUrkxy4wYGh3TWrBKojD4vf/IA0msCsZoJGQuoeiobN/6 73qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7yhkRd6f073YFMR5goDbFsS2fzyvIVrl94x/SsJzrBg=; b=bY54YElHTygTqe2u5xqJiMHv+r7MmlLLBnr/Jf2vXMh89A3XUMMW0JEtR5lbFMv0uV tsUPADEjOzIxQXfHsmJQqdV4TqfoKVTUJcq8Ep3Io+HCNF25i+6StAmr25SH0WlLgT7q SD6LnoPtHResdG5NzJbNcQlLY8bpSPeIu4J77Fj009VkfNnkDM7Wlq/m+PqWAFJR4by+ 6/6xnsylrhKW2uTArEgzceUq6sw85LiwlbRD/09dL91RE97x6wJ1w6/jWDqiCYhaqHtd pjEB+hRvqj9amkoiD4UKgeQfVXz8ewBdvQetPI47e7TEEYC6OfKOaUi0ryC6ibgfQLsy aSig== X-Gm-Message-State: AOAM533gFxpZ8XbhKk22ZelOUIBJLla54+MXCrilu7a6i9StmhTitPGI cn4KcJlCLb+mD06aEWPEQNS1ul54d24= X-Google-Smtp-Source: ABdhPJye/8ZNsPClneQzyydQRGpxAx4fmWBC0WlxNewFmwuGeLmb5UpSaleWrGePWNb8/hgkaGFOqw== X-Received: by 2002:a5d:6642:: with SMTP id f2mr11836658wrw.278.1629124403311; Mon, 16 Aug 2021 07:33:23 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n16sm11867571wru.79.2021.08.16.07.33.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:33:22 -0700 (PDT) In-Reply-To: <8735r9ii8b.fsf@gmail.com> 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:212036 Archived-At: On 16.08.2021 17:20, João Távora wrote: >>>>> 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. >>> That's a very extreme example, something that I wouldn't expect a >>> Lisp >>> program to do, without removing the properties shortly thereafter. >> >> And that *will* happen with Joao's approach, as soon as some package >> implements a Lisp completion backend in a certain (legal) fashion. > > There is no leak, not in the strong or weak sense. Eli already said that, in a sentence that I also quoted. And still: "I wouldn't expect a Lisp program to do ". > There is a constant > usage memory footprint proportional to the size of obarray, yes, but the > factor isn't huge. From the top of my head, I think it's about two > conses and a fp number for each sym. does anyone know how much that is > or can teach me how to measure? Thanks. If we say that your approach is legal, those are only "two conses and a number" coming from minibuffer.el. But since other packages will also be allowed to do that, the factor will only be limited by the amount of installed packages. > Anyway the current situation is constant copies of strings that put > pressure on the GC, as the benchmarks show. > > Anyhoo, in the interest of placating this string property bogeyman, I've > prepared a version of my patch that is based on weak-keyed hash tables. > Slightly slower, but not much. Here are the usual benchmarks: Cool, I'll take a look, thanks. >>> And even that isn't a leak. >>> Note that we already put all kind of properties (although not text >>> properties) on symbols. >> >> Those do not, generally, change over time. > > Neither does this one! At least in size, which is the thing that > matters. So in terms of "negative" consequences it's exactly > equivalent. Read the patch it will be obvious, I think. I was talking about the values of the properties, not the size in memory.