At Jump Development Group we enjoy running OptiMem on our development machines because we're always needing to stretch our machines further. However, since many of these tools aren’t the most robust programs, we check each one carefully to make sure optimization doesn’t tickle any of their problems/bugs.
In particular, it seems to work well with the version of ResEdit™ 2.1.1 which we use (especially amazing given the unusual things ResEdit does with memory, and its frequent problems when pushing its limits).
Resorcerer® also works well. With v1.2.4, we set the Minimum Size down to 400K.
We used it cautiously with MPW 3.2 after surgically removing a DebugStr call it issues frequently (though we certainly haven’t tested it with all the MPW commands and tools and there can be some tools that do very unusual things with memory). We have not done much testing with v3.3.1 yet. We have set OptiMem Off for MPW in the shipping configuration.
We test Think Reference with OptiMem on and a Minimum Size of 60K (as opposed to the built-in 640K). This doesn't save much memory unless you are using a limited set of reference files, but it reduces the fragmentation problem because it doesn't need the large fixed contiguous partition.
We do not use Symantec/Think C/C++ here but have begun testing with v6.0.1. We have used it with the Minimum Size for THINK Project Manager set at 1200K without problems. However, since it is doing very unusual and complex things with memory and there have been some reports from users with problems (but using previous versions of OptiMem), we have left OptiMem Off for it in the shipping configuration. Let us know your results if you turn OptiMem on for it.
----------------------
Programming Suggestions for Improved Optimization
Following are a few suggestions for programmers who want to make their applications work as effectively as possible with OptiMem. In general, just follow the Inside Macintosh® and other Apple® guidelines and everything should work well. In particular:
• Only allocate the amount of memory you really need and wait until you really need it. Then dispose of it as soon as you are done with it.
• Use Handles whenever possible (instead of Ptrs) and only lock the Handles when necessary (unlocking them again as soon as possible). This helps minimize fragmentation of memory and lets your users get full use of all their memory.
• Check for the availability of memory required right when you are ready to do the operation which needs it. And don’t check for some minimum amount of available memory before you will even launch the program: the user can free up more memory when they find there is not enough to do what they want.
• When you do check for available memory, always use the standard memory manager traps rather than accessing the system’s private globals or heap data structures directly.
• Always check for errors after allocating new memory. Don’t assume that any request will succeed. Whenever there isn’t enough memory to continue some operation, back out of it gracefully, letting the user know that more free memory is required, and let them continue with other things or let them retry the operation over again without forcing the user to quit. (Since the user will probably be able to free up some more memory by closing windows or other programs, if they need to.)
• Don’t take any chances with dereferenced Handle pointers going stale across calls to toolbox traps that can move memory, even if testing leads you to believe it won’t move in your case: if the book says the trap might move memory, assume that it will.
To find any such bugs, exercise your code using a heap scramble option in your debugger.
__________________________________
Jump and OptiMem are trademarks of Jump Development Group, Inc. All other trademarks are the property of their respective holders.
