From: Richard Stallman <rms@gnu.org>
To: David Kastrup <dak@gnu.org>
Cc: rudalics@gmx.at, kalman.reti@gmail.com, monnier@iro.umontreal.ca,
emacs-devel@gnu.org
Subject: Re: mark_object crash in 22.1 and latest CVS (as of tonight)
Date: Mon, 19 Nov 2007 14:03:15 -0500 [thread overview]
Message-ID: <E1IuBtr-0005rN-Su@fencepost.gnu.org> (raw)
In-Reply-To: <85y7cvm94t.fsf@lola.goethe.zz> (message from David Kastrup on Mon, 19 Nov 2007 00:22:42 +0100)
> 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.
next prev parent reply other threads:[~2007-11-19 19:03 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-09 3:55 mark_object crash in 22.1 and latest CVS (as of tonight) Kalman Reti
2007-11-09 11:32 ` Kalman Reti
2007-11-10 10:19 ` Kalman Reti
2007-11-11 5:22 ` Richard Stallman
2007-11-12 11:40 ` Kalman Reti
2007-11-12 22:03 ` Stefan Monnier
2007-11-13 0:30 ` Kalman Reti
2007-11-13 20:03 ` Richard Stallman
2007-11-14 17:39 ` Kalman Reti
2007-11-14 18:51 ` Stefan Monnier
2007-11-15 1:00 ` Kalman Reti
2007-11-15 17:09 ` Richard Stallman
2007-11-16 12:05 ` Kalman Reti
2007-11-16 14:07 ` Kalman Reti
2007-11-16 17:28 ` martin rudalics
2007-11-16 17:56 ` Kalman Reti
2007-11-17 4:54 ` Richard Stallman
2007-11-17 5:43 ` Kalman Reti
2007-11-16 19:04 ` Stefan Monnier
2007-11-16 21:52 ` martin rudalics
2007-11-16 22:09 ` Stefan Monnier
2007-11-16 22:16 ` Stefan Monnier
2007-11-16 23:59 ` Kalman Reti
2007-11-17 4:25 ` Stefan Monnier
2007-11-17 17:42 ` Richard Stallman
2007-11-18 3:08 ` Stefan Monnier
2007-11-18 22:45 ` Richard Stallman
2007-11-18 23:22 ` David Kastrup
2007-11-19 7:50 ` Stefan Monnier
2007-11-19 19:03 ` Richard Stallman [this message]
2007-11-17 4:53 ` Richard Stallman
2007-11-15 3:08 ` Richard Stallman
2007-11-15 8:38 ` Kalman Reti
2007-11-16 20:48 ` Kalman Reti
2007-11-16 21:59 ` Stefan Monnier
2007-11-16 23:09 ` martin rudalics
2008-02-04 11:35 ` buffer-undo-list (was: mark_object crash in 22.1 and latest CVS (as of tonight)) Johan Bockgård
2008-02-04 21:44 ` buffer-undo-list Stefan Monnier
2008-02-11 17:58 ` buffer-undo-list Stefan Monnier
2007-11-13 5:10 ` mark_object crash in 22.1 and latest CVS (as of tonight) Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1IuBtr-0005rN-Su@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=kalman.reti@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.