Re: Re: Re: Re: Re: Optimising processing for large data files.

[toma]

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.

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 from vmem.h:

/* vmem.h
 *
 * (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
+lic
 *    License or the Artistic License, as specified in the README file
+.
 *
 * Options:
 *
 * Defining _USE_MSVCRT_MEM_ALLOC will cause all memory allocations
 * to be forwarded to MSVCRT.DLL. Defining _USE_LINKED_LIST as well wi
+ll
 * 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
+lgorithm
 * is used; defining _USE_BUDDY_BLOCKS will use Knuth's algorithm R
 * (Buddy system reservation)

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.