see below... Rudy Lippan [[EMAIL PROTECTED]] wrote: > On Wed, 19 Dec 2001, Hardy Merrill wrote: > > > Tiele Declercq [[EMAIL PROTECTED]] wrote: > > > > > In the example above it SHOULD fetch data of 1 row, create a hash > > for it and return the reference. I thought this would be the most > > efficient way of fetching data but when running this script (without > > doing anything with the fetched data) it consumes >30Meg of RAM !!! > > I've read the Programming the Perl DBI book from O'Reilly and if I got > > it right it shouldn't do this ! It should replace the fetched columns > > with the newly fetched data. But it's clearly NOT doing this. > > > > > The "fetchrow_hashref" section of 'perldoc DBI' contains > > this paragraph - this is on DBI version 1.20: > > > > Currently, a new hash reference is returned for each > > row. This will change in the future to return the > > same hash ref each time, so don't rely on the current > > behaviour. > > > > So, currently a *new* hash reference is returned for each row - > > since memory is a concern, you may want to try one of the other > > fetch methods. > > A new hash is returned but the old one should get GC'd right? You > are assigning a new hash to $row and, assuming that, there are no other > referances to the old hash it should just go away when $row gets a new > ref, or am I missing something?
I'm curious about this now - it would seem that Rudy is right, that when the hashref scalar gets assigned the reference to the "new" hash, then the only existing reference to the old hash should disappear, which should in theory(?) make the memory taken by that old hash available again via garbage collection, right? Why isn't this happening? Tim, or anyone else know the answer? -- Hardy Merrill Mission Critical Linux, Inc. http://www.missioncriticallinux.com
