Re: How to debug memory leaks

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> "Source of a problem" is probably a bit too heavy expression :).  For
>> example if I have had a file with lots of undo history, I wouldn't say
>> it was a source of a problem, but I might decide that I wish to get rid
>> of the undo history, and start it from clean, without killing the buffer
>> and opening it a new.
>
> I don't think I've ever seen the undo history being a source of sluggishness 
> ;-)
>
>>>> I used undo history as example, but I ment bunch of other stuff. No idea
>>>> how much it would give in practice though.
>>> So, there's no concrete existing example of stuff that could be added to
>>> this "cleanup hook" :-(
>> I was trying to reason in terms of a general facility. What do I know
>> what people use, no idea what can be "throwable" in different modes.
>
> The problem is that sluggishness (just like excessive memory use) can
> come from many many different places.  So it's hard to come up with
> a tool that handles "the usual suspects" because there are too many
> usual suspects.

Indeed, and I didn't ment undo as a single of slugishness either, not
does it even have to be slughisness. That is why I say "bunch of stuff";
unspecified :-). I ment a single place where user, mode creators etc,
can add bunch of setq vars to nil and would be explicitly called by
user from some function; something like reset to starting state or some
kind of that. I said in some previous answer to Eli, I don't even
percieve later versions as sluggish. I got ideas when there was that
memory leak, and I just suggest it as a mechanism for the future, in
case of.

> What we have instead is `M-x profiler-start/report` which should(?) let
> you find out what is the source of the sluggishness.  Similarly we have
> a `M-x memory-report` for excessive memory use.
>
> They don't work great, admittedly, but this is a hard problem.

Better than nothing! :):