* Figuring out what's doing so much allocation
@ 2012-02-10 19:22 Jim Blandy
2012-03-21 3:49 ` Stefan Monnier
0 siblings, 1 reply; 2+ messages in thread
From: Jim Blandy @ 2012-02-10 19:22 UTC (permalink / raw
To: Emacs Devel
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
I was running into a problem (now fixed) in which gc was running
constantly, so I put together the following hack to figure out who was
doing the allocation. Set gc-quit-frequency to something like 20, and
then set debug-on-quit, and you'll get a backtrace every 20th gc. It's
hardly precise, but often one just needs a hint to suss out the cause.
[-- Attachment #2: gc-quit-frequency.patch --]
[-- Type: text/x-patch, Size: 1076 bytes --]
diff --git a/src/alloc.c b/src/alloc.c
index 044e750..3b98301 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -4998,6 +4998,14 @@ returns nil, because real GC can't be done. */)
int count = SPECPDL_INDEX ();
EMACS_TIME t1, t2, t3;
+ if (gc_quit_frequency) {
+ static int counter = 0;
+ if (--counter == 0)
+ Vquit_flag = Qt;
+ if (counter <= 0)
+ counter = gc_quit_frequency;
+ }
+
if (abort_on_gc)
abort ();
@@ -6359,6 +6367,7 @@ init_alloc_once (void)
byte_stack_list = 0;
staticidx = 0;
consing_since_gc = 0;
+ gc_quit_frequency = 0;
gc_cons_threshold = 100000 * sizeof (Lisp_Object);
gc_relative_threshold = 0;
}
@@ -6380,6 +6389,9 @@ init_alloc (void)
void
syms_of_alloc (void)
{
+ DEFVAR_INT ("gc-quit-frequency", gc_quit_frequency,
+ doc: /* *Quit every this many GC's. If zero, don't. */);
+
DEFVAR_INT ("gc-cons-threshold", gc_cons_threshold,
doc: /* *Number of bytes of consing between garbage collections.
Garbage collection can happen automatically once this many bytes have been
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: Figuring out what's doing so much allocation
2012-02-10 19:22 Figuring out what's doing so much allocation Jim Blandy
@ 2012-03-21 3:49 ` Stefan Monnier
0 siblings, 0 replies; 2+ messages in thread
From: Stefan Monnier @ 2012-03-21 3:49 UTC (permalink / raw
To: Jim Blandy; +Cc: Emacs Devel
> I was running into a problem (now fixed) in which gc was running
> constantly, so I put together the following hack to figure out who was
> doing the allocation. Set gc-quit-frequency to something like 20, and
> then set debug-on-quit, and you'll get a backtrace every 20th gc.
> It's hardly precise, but often one just needs a hint to suss out
> the cause.
Reminds me that we indeed should add some kind of sampling
based profiling.
The sampling could be "every N μs" or "every N allocated bytes", but it
would be really neat to be able to say "Hmm.. what has my Emacs process
been doing for the last 10s" and get some overview.
It shouldn't be that hard to implement, since we have the Lisp backtrace
readily at hand in a global variable.
Stefan
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-03-21 3:49 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-10 19:22 Figuring out what's doing so much allocation Jim Blandy
2012-03-21 3:49 ` Stefan Monnier
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.