[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: framers@xxxxxxxxxxxxxx (Framers List)
Subject: Solving Memory Problems on Windoze
From: DW Emory <danemory@xxxxxxxxxxxxxxxxxx>
Date: Tue, 01 Apr 2003 10:32:15 -0800
Cc: "FrameSGML List" <FrameSGML@xxxxxxxxxxx>, "Free Framers" <framers@xxxxxxxxx>
Sender: owner-framers@xxxxxxxxx
On Win98 2E, I'm using a supplemental memory management software product called FreeMem Pro. Although FreeMem automatically de-allocates memory when it drops below a user-specified critical threshold, it is also possible with FreeMem to manually de-allocate a substantially larger amount of memory. An icon for FreeMem appears in the bottom bar in Windows, and indicates the amount of physical memory (in K bytes) which is currently available. Clicking the icon opens FreeMem, allowing you to perform various operations, incuding manually de-allocating a large block of memory. I also use Norton System Doctor to monitor Mem Free, PM (physical memory) Free, and memory Cache Used. As would be expected, the amount of free memory indicated by the FreeMem icon closely tracks the amount of memory indicated by the Norton PM Free and Cache Used monitors. When I finish using an application, close it, and then manually de-allocate a large block of memory with FreeMem, I often find that the Norton PM Free and Cache Used monitors indicate a significant drop-off in the amount of memory which is free, (i.e., much less memory is available than was available before running the application, even thought no other applications are running). In addition, the Norton Mem Free monitor indicates an even more precipitous drop-off in the amount of available memory which Windows 2E "thinks" is available. For example, the Norton PM free monitor might indicate that 60% of memory is free, but the Mem Free monitor indicates that only 12% of memory is free. Regardless of what the Free Mem, PM Free, and Cache Free monitors indicate, when the Norton Mem Free monitor approaches zero, computer performance begins to slow down markedly, and the only way to recover performance is to re-boot. This problem is particularly vexing when intensively modifying, printing, or outputting postscript in very large FrameMaker files. So, here's the procedure I've developed which seems to solve the problem: I use FreeMem to manually de-allocate a large block of memory in the following situations. A. Immedately after opening FrameMaker B. Immediately after closing a FrameMaker file and before opening a new file C. Immediately after opening a new FrameMaker file. D. Immediately before closing FrameMaker. This procedure also seems to work just as well with other applications, and, although it is somewhat onerous, it is far less so than all the alternatives. Since, I believe, FreeMem (or similar memory de-allocation products) also work on Win 2000 and XP platforms, the same procedure might also be useful on those platforms. FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory <danemory@globalcrossing.net> ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **