Yes - for my application, I need to maintain a separate copy of the original array, which is then compared for changes to the original array. I need to be able to consistently return the original array to its initial (populated, not REDIM'd) state after each set of changes
While I am a self-confessed lover of memory-mapped files, I think an MMF might work well here. Save the original array in a disk file... since it's all LONG integers, the records are all the same size (SIZEOF(LONG), a syntax not added to CC5).
When compare time comes, you just memory map and view the file, and refer to individual long integers by offset from the start of the file, Or use the the mapped view of the MMF as the underlying memory for an absolute array, technique shown here: Memory Mapped Files instead of RANDOM disk file access 5-8-04
Advantages:
1. Memory for the original array is now charged to Windows, not to your process.
2. If you are low on the TOTAL memory available, you can MapViewOfFile in pieces for the compare, reducing RAM usage even more.
3. You are not using valuable system memory for your process except when you need it, which should enhance performance for all processes on the system when you are not using it. If you want to verify the memory use improvement, you can always insert checks using Add Process Memory Usage Report to any program 1-12-04
Disadvantages:
1. You have to invest the time necessary to copy and paste my demo code and read the doc on MMFs. Wait a minute, reading up and learning about MMFs is an advantage, not a disadavantage!
MCM
Leave a comment: