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 11:15:28 +0100 Message-ID: <56CD82C0.9080302@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> 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 1456310182 20963 80.91.229.3 (24 Feb 2016 10:36:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Feb 2016 10:36:22 +0000 (UTC) Cc: larsi@gnus.org, 18522@debbugs.gnu.org To: Eli Zaretskii , Peter =?UTF-8?Q?M=C3=BCnster?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 24 11:36:10 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 1aYWni-00072K-2L for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Feb 2016 11:36:10 +0100 Original-Received: from localhost ([::1]:34996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYWnh-0005V1-IN for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Feb 2016 05:36:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYWne-0005Uq-Fe for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2016 05:36:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYWna-0008QO-EC for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2016 05:36:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYWna-0008Pz-Ah for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2016 05:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aYWna-0002uk-3k; Wed, 24 Feb 2016 05:36:02 -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 10:36:02 +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.145631014511180 (code B ref 18522); Wed, 24 Feb 2016 10:36:02 +0000 Original-Received: (at 18522) by debbugs.gnu.org; 24 Feb 2016 10:35:45 +0000 Original-Received: from localhost ([127.0.0.1]:42514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYWnI-0002uF-QW for submit@debbugs.gnu.org; Wed, 24 Feb 2016 05:35:44 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:62544) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aYWnG-0002u0-IS for 18522@debbugs.gnu.org; Wed, 24 Feb 2016 05:35:42 -0500 Original-Received: from [192.168.1.101] ([212.95.7.120]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LyVIk-1ZuMMr2n14-015tNa; Wed, 24 Feb 2016 11:15:35 +0100 In-Reply-To: <8360xfjsyr.fsf@gnu.org> X-Provags-ID: V03:K0:29riLDnAyTgvkCF8YXtPte3YnUVUr9A8QSv8nmKexTUkA4/LldW TVel48+NEFCgJYhh+y1FowB0sztHRuDyxM49TdYUxocKC2i4/vRAR04amORMbGRBQlHCSSE e3ccBR8qz1dOr+HSZ57tznF4gqpCnfwBxpVE3Izt3lPGcmhX9oumMLEIYeWYCf0bV1dZHup cr5b8kTD/x3cY3Uw9heWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:CfsRRFrKJws=:uJ+i4tSc8pekwxdF/dduNW 0DEgrxoD8m5m5wLGnNRoOZ2Qbiz4brTisLqn+1//2K/Z4pkWMp6VEhLEbggdt4eynDQ5Nb2ml G4WGRppd+oR/t2Qph4KUca1KhxSCHv2JvhjGogULNhY8V7BielIYhu5L7FA539jSWRgiKf9D/ Qtj+4YG9bfoNoORveyK6F0DQu1vkE6ZrLZmD6DMuOhLqjL2O8wjupm8yVtPYJDSnfuXcaQr0t ExWcjTPzJS0k8z8TbJRHG4SVQZ71MCBL5jg/4Bbv5EoJQygWyiiNWLu3l1b78kTFbDyTc04d6 RPt/5+zAl7zeL8KS7LeJFnIwLt2HAFpvKWY9QstNmX/xXsX9+ksbl1FXXJsH8s6m6cfbSoawr AjNlHpa3EVWlSi5zP81zYPesfekGzlSOm08CoqVGNRXQsCkrKifLF8edYO5pnnYDXUJhJ05e5 PW5PkBqLN6lV5BQ97SJEyhDFyqwfncNfCRIIW9BTiwUK/akz0eXmbfg2glqxDN511rTjks48+ tPvWw/UEZ8wdrj0crTptf/1x3Z3Ib+DcOzKDliZj3mEu5gCntulkxOsYb7GjZY6CjKU/n8943 h+3+spqtMzlUjUdSmyVFkL9n4SjtwI9AJqtZbATiJmg7gGMxHnfJEXS3IU73nqulMNkLqs97i DOaU+p61cKORTdUuIYxdxHsiWIz9D7zTKcg1/wm3fHOBxzJCBZjJdz5ucNYfy5byt3MK9aedw OsRasLkitW2WsJm1u347borBt65JviAraPuWzORtPAzSt9gXLPEINup5o/FoNOqlmA/mDNFD 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:113702 Archived-At: > You interpret that comment too literally: it means killed buffers that > were not yet GC'ed. You will see in alloc.c that sweep_buffers > removes killed buffers from all_buffers and recycles their memory. Doesn't that remove unmarked buffers only? >> That means, the chain gets bigger and bigger, whenever I read an article >> or I reply or I send a new message or whatever. > > If Emacs did that, it would have been a very serious bug and a huge > memory sink. One potential hole are window configurations. Each window maintains two lists for navigating the buffers previously shown in that window. For live windows, these lists are hopefully updated when killing a buffer. But if you store such a window in a window configuration and forget about that configuration, the buffers from those lists are not reclaimed IIUC. BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c. martin