Sam wrote:
> Hi,
>
> I found many references to the 'memory leak' in the archived 
> messages at http://www.mail-archive.com/perl-win32-
> [EMAIL PROTECTED]/.

> I believe there isn't a memory leak at all, it appears that the 
> memory usage reported by windows task manager includes a 
> portion of a windows cache allocated to the program, and that it's 
> the cache usage that changes, not the amount of memory that the 
> perl interpreter has allocated.

oh well, I'm really confused now :-)

> This is based on these observations:
> 1)      As the memory usage reported by the task manager increases 
> the total memory usage does not increase. If you run a compiler or 
> something that will allocate memory a bit at a time for a long period 
> of time you'll notice that as the compiler's memory usage goes up, 
> and so does the total memory usage.

yes, this is true.

> 2)      If you minimize the perl-win32-gui app's window the reported 
> memory usage goes down to a base value (120K with my perl), and 
> every time you minimize the window it goes down to the same 
> value. This is _not_ indicative of a memory leak.

this is true too.

> 3)      If you play with other applications in a similar way you
> can make them exhibit similar behaviour. The reported memory usage
> on other applications (my test was EditPlus) doesn't increase to 
> the same extent, but it does increase (more on this difference later).

and this is true, but there are other applications (for example,
the NT Task Manager) which does not exhibit this behaviour, even
if they're left running for a large amount of time. and the Task
Manager updates its contect each second, so is doing something.
but its cache memory never grows up. damn :-(

> During the above I looked over the code involved, and attempted
> to isolate a memory leak. So far as I can tell the code is rock
> solid.

way cool ;-)

> I believe that the difference between a perl-win32-gui application, 
> and other pure win32 applications is in the DefWindowProc 
> handling. The perl-win32-gui module does call DefWindowProc 
> when either you don't have a handler installed, or you return 1, 
> however through BoundsChecker I believe that this may not always 
> be the case.

I'm really interested in this: can you elaborate more on this
point? do I call DefWindowProc too much, or it is not called
when it should be?

> I would be interested if someone finds anything else out about
> this problem. Unfortunately I can't spend any more time on this,
> as it appears to me that this isn't a serious bug, at least not
> something that will stop a program from working correctly.

well, a 4k increment for each mouse movement is quite too much,
so something should be corrected (if it's not totally wrong, it's
surely at least poorly coded :-)

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;



Reply via email to