View Single Post
Old 5th March 2003, 16:48   #23
Jacob Metro
Junior Member
 
Jacob Metro's Avatar
 
Join Date: Nov 2002
Location: Alabama, United States of America
Posts: 31
Send a message via AIM to Jacob Metro Send a message via Yahoo to Jacob Metro
Wink Info on the problem

I've done a little research

I don't have the best of all systems to test with, but I use it for customer work so I guess it will have to do for this as well.

I am using Windows 2000 Pro, NTFS, AMD 850, 768MB RAM.

Attached is a file named NSIStst.RAR. THIS IS NOT A RAR FILE. This is a CSV file produced by the W2K performance monitor. Simply download this file, rename it a CSV file, and open it using MS Excel (or your spreadsheet viewer). I asked the performance monitor to watch several counters while I ran NSIS.

Here's what I have found.

With a 1.57GB set of files using STANDARD compression (ZLIB), compresses fine.

However that same set using (I'm guessing) ENHANCED compression (BZIP2), does not compress fine and errors out with the #12345 error.

The CSV file shows a substantial memory leak using BZIP2. The \Memory\Available MBytes counter begins by showing 640MB ram at the start of the program and ends with 16MB ram before the error.

Secondly, using BZIP2 compression (and I'm a newbie programmer so I don't really know what this means, if anything) there is a problem with the Windows 2000 Task Manager's CPU Time column for MAKENSIS on the Process page. Let me put it another way. My System Idle Process just keeps on ticking. My CPU usage is between four and ten percent. But disregarding all these factors, the CPU Time column is not updated as regularily as I would like (even putting the process' priority at "real-time"). In fact before failure the CPU Time column shows 33 seconds worth of work time. My stop watch shows 10 Min 19.8 Sec worth of work time.

For control purposes my test run using STANDARD (ZLIB) compression used 18 minutes 30 seconds worth of processor time.

As far as I've seen (a 400MB test, 800MB test, 1GB test, and this 1.57GB test) this "leak" does not occur using standard compression.

So my guess is that for some reason BZ2, isn't leaning as heavily on the processor as it could and is thus eating up too much memory. That, in itself, could break the 2GB barrier.

I left other counters in the CSV file which I thought may be of benefit to a more advanced programmer.

I really appreciate the NSIS Scripting Language. It is a powerful tool.

Sincerely,
Jacob Metro
Attached Files
File Type: rar nsistst.rar (42.6 KB, 234 views)
Jacob Metro is offline   Reply With Quote