Re: Odd (undocumented?) behavior of RAM file within a loop
- From: Ben Morrow <ben@xxxxxxxxxxxx>
- Date: Wed, 30 Jan 2008 12:53:55 +0000
Quoth "A. Sinan Unur" <1usa@xxxxxxxxxxxxxxxxxxx>:
Ben Morrow <ben@xxxxxxxxxxxx> wrote in
news:8v2575-srt.ln1@xxxxxxxxxxxxxxxxxxxxxxx:
This makes less sense... I suspect what's happening here is that the
filehandle isn't being closed until *after* $buffer gets allocated for
the next iteration, so it is forced to allocate a new scalar since the
old one's still in use.
That is my gut feeling, too.
This is arguably wrong, since the whole point is to reuse the old
scalar if we can, for efficiency.
In fact, I would argue that it is wrong. I don't foresee myself being
able to first find where this is occurring and fix it without messing up
anything else.
On the other hand, when I used an infinite loop to see if this behavior
caused a leak, it seemed to just cycle through the same three locations
and memory usage did not increase at all.
No, I wouldn't expect that. The filehandle should still be getting
closed, just not until after $buffer has been reallocated. At that point
the old value of $buffer will be freed, so it's likely that some scalar
will 'soon' reuse its memory.
Ben
.
- References:
- Odd (undocumented?) behavior of RAM file within a loop
- From: David Filmer
- Re: Odd (undocumented?) behavior of RAM file within a loop
- From: A. Sinan Unur
- Re: Odd (undocumented?) behavior of RAM file within a loop
- From: Ben Morrow
- Re: Odd (undocumented?) behavior of RAM file within a loop
- From: A. Sinan Unur
- Odd (undocumented?) behavior of RAM file within a loop
- Prev by Date: Re: C's gotoxy() equivalent in Perl
- Next by Date: Re: CRLF problem.
- Previous by thread: Re: Odd (undocumented?) behavior of RAM file within a loop
- Next by thread: FAQ 9.15 How do I parse a mail header?
- Index(es):
Relevant Pages
|
