It would be interesting to try a few variations
on this code, such as not using lexical variables,
to isolate the cause of this behavior. Another
source of memory strangeness could be the file system.
in reply to Re: Re: Re: Re: Optimising processing for large data files.
in thread Optimising processing for large data files.
If you look in the win32 directory of the Perl source
code, you will see that there are several ways to
change the way that perl allocates
and frees memory, in 5.8.0, at least. Here's a snippet
I don't know how ActiveState perl was built. It's
probably in Config.pm somewhere, though. The comment
about _USE_LINKED_LIST leads me to believe that there is
a memory leak, which can be fixed at the expense
of using more memory. My guess, based on your
observations, is that ActiveState perl has this leak.
Also, you might possibly have a version
of MSVCRT.DLL installed which is not the one that
ActiveState had in mind for you to use.
* (c) 1999 Microsoft Corporation. All rights reserved.
* Portions (c) 1999 ActiveState Tool Corp, http://www.ActiveState.com
* You may distribute under the terms of either the GNU General Pub
* License or the Artistic License, as specified in the README file
* Defining _USE_MSVCRT_MEM_ALLOC will cause all memory allocations
* to be forwarded to MSVCRT.DLL. Defining _USE_LINKED_LIST as well wi
* track all allocations in a doubly linked list, so that the host can
* free all memory allocated when it goes away.
* If _USE_MSVCRT_MEM_ALLOC is not defined then Knuth's boundary tag a
* is used; defining _USE_BUDDY_BLOCKS will use Knuth's algorithm R
* (Buddy system reservation)
It should work perfectly the first time! - toma