Memory Leak (AREV Specific)
At 13 DEC 2011 01:12:14PM Victor Engel wrote:
It's been a while since I've posted here.
I can't believe I've never noticed this before, but it seems like PCPERFORM has a memory leak. We've got a process running that does thousands of PCPERFORMs during a session, and performance was deteriorating over time. I opened up the Windows process manager and noticed NTVDM was using over 500 MB of memory. Since then, I've been trying to track down the source of the memory leak, and it seems to be PCPERFORM. I've just been running a loop that basically runs a null batch program, and after a couple thousand iterations, the memory leak added up to about 250 bytes per PCPERFORM. Any suggestions?
At 13 DEC 2011 01:13PM Victor Engel wrote:
P.S. This is Arev 2.12.
At 14 DEC 2011 07:52AM Dave Harmacek wrote:
Have you tested an alternative:
PC EXIT routine
?
At 14 DEC 2011 11:31AM Warren Auyong wrote:
What happens if you use EMS Magic?
At 14 DEC 2011 12:05PM Victor Engel wrote:
Same thing.
It looks like the bulk of the shelling is done to create subdirectories. Is there a way to create a subdirectory from Arev without spawning a DOS shell?
At 14 DEC 2011 12:50PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
http://www.sprezzatura.com/library/revmedia/vol2-iss4-art1.php
World leaders in all things RevSoft
At 14 DEC 2011 03:35PM Victor Engel wrote:
Thanks. I guess I should have known that already.
At 15 DEC 2011 11:41AM Eric wrote:
To answer your question, the DOS session and its environment block is never released by Windows. The offsets of AREV sessions in memory are 256 bytes different for Windows as against the same exe in raw DOS sessions.
At 17 DEC 2011 06:26AM Dave Harmacek wrote:
Can you instead write a DOS batch file with those thousands of entries and run it as a large batch?
At 28 DEC 2011 10:08AM Victor Engel wrote:
In fact, that's what is done after the documents are created. They are all gzipped and then zipped up in batch. The problem was in creating the directory structure, which has been resolved with the solution posted by The Sprezzatura Group. The process also runs much faster now.