One thing I'd recommend (if you aren't doing this already) is to build a memory profiler component with an action that dumps your memory profile data. Then you can run zillions of queries without paying the price of the memory profiler per hit, while still having your data always be accessible.
If one of these was easily available, then I wouldn't have to write my own when I start working on memory leaks. Hint, hint. Scott On 8/15/06, Steve Longdo <[EMAIL PROTECTED]> wrote: > On TextDrive the profiling code has enough overhead it kills the thread > sometimes. I have noticed that the number of Blog objects seems to stack up > over time though. I've seen as many 22 instantiated at the same time. > Considering that I only have one Blog that seems kind of high. > > Granted they don't take up much memory themselves, but I wonder if they hold > on to arrays of Content objects and prevent them from being garbage > collected. I am still digging into it. > > > On 8/15/06, Piers Cawley <[EMAIL PROTECTED]> wrote: > > "Scott Laird" <[EMAIL PROTECTED]> writes: > > > > > On 8/15/06, Scott Laird <[EMAIL PROTECTED]> wrote: > > >> On 8/15/06, Josh Knowles < [EMAIL PROTECTED]> wrote: > > >> > On 8/15/06, Josh Knowles <[EMAIL PROTECTED]> wrote: > > >> > > I thought it might be something like this but was given no log > message > > >> > indicating that my process was being killed. Thanks for the link and > the > > >> > shove in the right direction! > > >> > > > >> > So even with the removal of the majority of the components my two > processes > > >> > are still hovering around 42-48meg, is this normal? > > >> > > > >> > Josh > > >> > > >> That's still higher then I'd like to see, but it's within the range > > >> that people have reported. > > > > > > ...and having said that, I just checked mine, and I'm seeing 56-62 MB > > > after two days. And, more annoying, it's racked up about 9 hours of > > > CPU time along the way. Admittedly, this is a slow box (Athlon 700 > > > Mhz), and my blog is fairly busy. > > > > > > I'm not focusing on doing a lot of speed or memory improvements with > > > 4.0 right now. I'm going to release 4.0.3 with a couple more bug > > > fixes soon, but after that I'm going to start concentrating on Typo > > > 4.1. One of the big goals for 4.1 is performance; if I find anything > > > big and obvious, then I'll back-port the change to 4.0, but I don't > > > want to experiment with 4.0--that's what 4.1 is for. > > > > I wonder how much affect the new regime of including more things has > > had on memory usage? In theory we could be far more particular about > > when we fetch stuff, but then we end up paying with more load on the > > database server. It's all about the trade offs I'm afraid. > > > > -- > > Piers Cawley <[EMAIL PROTECTED]> > > http://www.bofh.org.uk/ > > _______________________________________________ > > Typo-list mailing list > > [email protected] > > http://rubyforge.org/mailman/listinfo/typo-list > > > > > > -- > Thanks, > -Steve > http://www.stevelongdo.com > _______________________________________________ > Typo-list mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/typo-list > > _______________________________________________ Typo-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/typo-list
