From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: mark_object crash in 22.1 and latest CVS (as of tonight) Date: Mon, 19 Nov 2007 14:03:15 -0500 Message-ID: References: <16af2f430711081955j3d5e6745gc0f7a50e02d9a892@mail.gmail.com> <16af2f430711120340q27926877tf976ef397d12df16@mail.gmail.com> <16af2f430711140939x45663644je0dce25c8796b18@mail.gmail.com> <16af2f430711141700g74175advd8f234478293faa5@mail.gmail.com> <16af2f430711160405p6a734839lb24610ee65257498@mail.gmail.com> <16af2f430711160607m158b9c98xa401166709f628ff@mail.gmail.com> <473DD32F.5070501@gmx.at> <85y7cvm94t.fsf@lola.goethe.zz> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1195499306 31288 80.91.229.12 (19 Nov 2007 19:08:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Nov 2007 19:08:26 +0000 (UTC) Cc: rudalics@gmx.at, kalman.reti@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 19 20:08:31 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IuBxs-0007ZI-QR for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2007 20:07:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IuBxf-0006na-9T for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2007 14:07:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IuBtw-0004G2-Co for emacs-devel@gnu.org; Mon, 19 Nov 2007 14:03:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IuBtt-0004CT-Ms for emacs-devel@gnu.org; Mon, 19 Nov 2007 14:03:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IuBtt-0004C6-8i for emacs-devel@gnu.org; Mon, 19 Nov 2007 14:03:17 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IuBts-0003yi-Qr for emacs-devel@gnu.org; Mon, 19 Nov 2007 14:03:16 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1IuBtr-0005rN-Su; Mon, 19 Nov 2007 14:03:15 -0500 In-reply-to: <85y7cvm94t.fsf@lola.goethe.zz> (message from David Kastrup on Mon, 19 Nov 2007 00:22:42 +0100) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:83680 Archived-At: > Yes, that's the crucial question. It should be easy to get some > numbers by running an interactive application that often uses > save-match-data and compare the memory usage and amount of GC of the > two versions. The problem is not the memory usage: garbage collection will set in anyway when the memory is tight. In Emacs, GC doesn't occur when memory is scarce; Emacs doesn't measure that. GC occurs based on the amount of consing done. If the markers are not freed, Emacs will allocate more space for markers. The problem is that editing becomes awfully slow in a buffer with many markers. And temporary markers created with save-match-data will only be unseated from the buffer once they get collected. That is also a factor, indeed. Perhaps it would be a useful idea to have the "evaporate" argument only unseat the markers from the buffer (the equivalent of (move-marker marker nil)) without garbage-collecting it. That would be the basic RESEAT functionality in `set-match-data'. Perhaps it is the right thing to do, but I still wonder how much extra space the extra GCs will cause. It occurs to me that free_marker could un-count the consing of that marker, so that GC would also happen less often.