From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: mark_object crash in 22.1 and latest CVS (as of tonight) Date: Mon, 19 Nov 2007 02:50:10 -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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1195458642 18996 80.91.229.12 (19 Nov 2007 07:50:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Nov 2007 07:50:42 +0000 (UTC) Cc: rudalics@gmx.at, kalman.reti@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 19 08:50:48 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 1Iu1P1-0005ae-K1 for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2007 08:50:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iu1Oo-0003wQ-2A for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2007 02:50:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iu1Oh-0003uZ-Ev for emacs-devel@gnu.org; Mon, 19 Nov 2007 02:50:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iu1Og-0003tx-VN for emacs-devel@gnu.org; Mon, 19 Nov 2007 02:50:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iu1Og-0003th-Ff for emacs-devel@gnu.org; Mon, 19 Nov 2007 02:50:22 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Iu1OX-0005K5-Q8; Mon, 19 Nov 2007 02:50:14 -0500 Original-Received: from tomts13.bellnexxia.net ([209.226.175.34] helo=tomts13-srv.bellnexxia.net) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iu1OW-0003DJ-VQ; Mon, 19 Nov 2007 02:50:13 -0500 Original-Received: from ceviche.home ([70.55.147.211]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20071119075011.JYTR13659.tomts13-srv.bellnexxia.net@ceviche.home>; Mon, 19 Nov 2007 02:50:11 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 07D5EB4027; Mon, 19 Nov 2007 02:50:10 -0500 (EST) In-Reply-To: <85y7cvm94t.fsf@lola.goethe.zz> (David Kastrup's message of "Mon, 19 Nov 2007 00:22:42 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by mx20.gnu.org: Solaris 8 (1) 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:83616 Archived-At: >> It's an "optimization" and nothing more. In my book, if an >> optimization is unsafe, it had better make a good case for itself. >> As it stands I see no evidence that this optimization is ever >> useful. As long as nobody can show us numbers that demonstrate a >> measurable performance impact, I think we're better off without >> this optimization. >> >> 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. Someone needs to write the "optimized" but correct version first. > The problem is not the memory usage: garbage collection will set in > anyway when the memory is tight. > 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. No: the current code (where I removed the `evaporate' optimization) still unseats the markers right away. It just doesn't free them. > 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's already what the `unseat' argument does (which used to accept a special `evaporate' value to imply that it shouldn't just unseat but also free). Stefan