From: "ara.t.howard" Date: 2007-09-29T02:36:52+09:00 Subject: Re: [ANN] dike-0.0.1 - a memory leak detector On Sep 28, 2007, at 11:26 AM, Joel VanderWerf wrote: > That looks very useful. I'm not sure "leak" is the term I > would use, since the objects are reachable. Unused reachable > objects can be just as much of a problem as unreachable objects, of > course. > agree. we seem to be the minority though ;-( > If you have Strings created in two places, are they reported > separately in the output? I assume so, but I couldn't tell from > your examples. If you're looking for trouble spots, it would be > useful to know not just that there were N strings floating around, > but that N1 of them were created on line L1, N2 on line L2, and so on. > yeah, that's *exactly* what it does. of course some objects, like a = [], do not allow ruby hooks to track them so they just get reported under the general stacktrace of '[]', but at least they are reported. > Does this have much of a cost on performance? (It doesn't use > trace_func, does it?) I'd like to have something like this enabled > by default for long-running deployed processes, not just in debugging. > not really. it addes hooks into Object#initialize and Class#new to make sure the creation is stored via caller. the location is stored in a big hash with finalizers to remove entries (object_id => stacktrace of creation). no reporting is done unless you call Dike.finger which, with the rails hooks, is done after every request. so i wouldn't say it has now performance hit, but it should be a lowish hit. i'd be very happy to get some feed back. so far it's been very useful - i've been able to find several leaks in rails (i think) which i'm looking into now. it found 5 leaks in my app and i was able to fix them easily in about 10 minutes, so that's nice. cheers. a @ http://drawohara.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama