From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#18522: 24.4.50; mapcar is very slow Date: Wed, 24 Feb 2016 19:16:27 +0100 Message-ID: <56CDF37B.6050002@gmx.at> References: <8738bkdjqg.fsf@micropit.roche-blanche.homenet.org> <87wpqh9gm3.fsf@gnus.org> <87io1nnx88.fsf@roche-blanche.net> <87vb5l8en7.fsf@gnus.org> <83wpq1rt5o.fsf@gnu.org> <8737so5neo.fsf@gnus.org> <831t87re7a.fsf@gnu.org> <87bn7b3hnz.fsf@roche-blanche.net> <83lh6fpv4z.fsf@gnu.org> <87h9h2xr9k.fsf@roche-blanche.net> <56C99AD0.2000309@gmx.at> <87wppywbaz.fsf@roche-blanche.net> <87d1rquo4a.fsf@roche-blanche.net> <878u2eun9o.fsf@roche-blanche.net> <834md2niqt.fsf@gnu.org> <87k2lyszy2.fsf@roche-blanche.net> <83bn79n66p.fsf@gnu.org> <87vb5hry9y.fsf@roche-blanche.net> <83r3g4lnor.fsf@gnu.org> <87r3g4o4uw.fsf@roche-blanche.net> <83h9h0jwfo.fsf@gnu.org> <87mvqru119.fsf@roche-blanche.net> <8360xfjsyr.fsf@gnu.org> <56CD82C0.9080302@gmx.at> <83twkygg32.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1456337842 15013 80.91.229.3 (24 Feb 2016 18:17:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Feb 2016 18:17:22 +0000 (UTC) Cc: larsi@gnus.org, pmlists@free.fr, 18522@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 24 19:17:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aYdzq-0002VA-HJ for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Feb 2016 19:17:10 +0100 Original-Received: from localhost ([::1]:37541 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYdzq-0007m6-02 for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Feb 2016 13:17:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYdzl-0007jg-31 for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2016 13:17:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYdzh-00073J-Tq for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2016 13:17:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYdzh-00073F-R7 for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2016 13:17:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aYdzh-0002i9-NF; Wed, 24 Feb 2016 13:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bugs@gnus.org Resent-Date: Wed, 24 Feb 2016 18:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18522 X-GNU-PR-Package: emacs,gnus X-GNU-PR-Keywords: Original-Received: via spool by 18522-submit@debbugs.gnu.org id=B18522.145633780710399 (code B ref 18522); Wed, 24 Feb 2016 18:17:01 +0000 Original-Received: (at 18522) by debbugs.gnu.org; 24 Feb 2016 18:16:47 +0000 Original-Received: from localhost ([127.0.0.1]:44122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYdzT-0002hc-J8 for submit@debbugs.gnu.org; Wed, 24 Feb 2016 13:16:47 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:58315) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYdzR-0002h4-6A for 18522@debbugs.gnu.org; Wed, 24 Feb 2016 13:16:45 -0500 Original-Received: from [192.168.1.100] ([212.95.7.18]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lt2BW-1ZolLT1y8I-012cAF; Wed, 24 Feb 2016 19:16:37 +0100 In-Reply-To: <83twkygg32.fsf@gnu.org> X-Provags-ID: V03:K0:0YHMAm/IjgUfssG4tnqfRVwvD9bXFVxDmZ++UsqDo4enT1XXmLF RZoe36UPiMH+OWRk4OtXziCfzyt+nOet7xPCPMRzY367ADW4vWVJ2HkhaqBDKcnGq9o3H4K yyQj/u6asYUzmrLIrx9vx9VC8uvNce5Chn5SvqCipxH2sVuO17oTJQgex4M+aVEtS3KTDon zpjNjvHGl9icWmbl/Og0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:pWx4bVZuXv0=:LOmsRrUDjL6aygjg3ngyKJ HzFytDLxwRajMTub7Apy0XRkK6LpgA3RgnggUgFZ4Lgd+q5yhNxJOzoqW476oLEhbamtoFGIq n1NCVpg9HkUOz7Z9jxjzyFF+J0FVFCA5m4SrH0YXHVWKX4CYtvdpSE8etHi7pl6fYqC//P8bA 0T8Kqp96KAazUsMOuMW74G19QMaxwBtORdmxaUFpj71mYC3zqAiH1Of2lUOaf+AKEYhxeElwV Cs8uUX18H5eLs40F1djT4p9IFr1LIZ/o/GZkIv0NEu5M373KoVQT4oNNOrCeN8hh15EBHjrl0 vy2BSChAt3Z+lqIQnK+aBDB4PMwERjjcXu1ltgFsgRvZnTwZ4YaZiDWJ6cDOd6OErgVQ5JHpf YcPAWctWU8iN6R7RzKxh9I2pBYQNVXSEYK+Ca+3OL8HtHsrqCkkpIcq5V0OrB9k3MzyZKoudx 8ECK3IhhhGaELcd4p2tlgqbXIzdGDXIjhbo29n3+BETkjJHqJVW4PJ9BeTvXOMUdLc+r9B/AL WCQINL8n2aPvR4jwNydOb/UUU/KSnt7Dk1C3ht8yircwG0vvfoGmKYMu/c2dqzPiBt/hlekFl lxP7H++5lMqVf0AeobdXYicJHetwx5ckq6VZovhipDT70270p4jy9LLV+OJoHCly9W+kyh75z 0NSUL6hl8xhJMC/qgdvucXFAli14WPkGI+cPuD3/kppu4ZJP+UiORd0PZyGzgiADu9GMA54TS PNFvoOSvVA5DpunAHfOGerE4lTcFSjiw/httTrHs8hpnAwqPEWYKzg35VwKwkVsqYrbRZbI1 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113731 Archived-At: > Of course. But why would killed buffers be marked? Because they are still referenced from somewhere else. > What do you mean by "forget"? Forgetting a Lisp object means it is > not referenced by any other object, so it will be GCed, together with > the buffers it references. Right? Each window in a window configuration stores all the buffers it has ever shown. Now window configurations are sometimes stored in registers. I could imagine users that store a couple of configurations in registers and "forget" about them in the sense that they do not restore from some of those stored configurations for quite some time or the rest of the session. >> BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c. > > What would you use instead? A macro that excludes killed buffers. What's the purpose of if (!PER_BUFFER_VALUE_P (b, idx)) set_per_buffer_value (b, offset, value); in a killed buffer? martin