From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2002-10-07 16:34:49
On Mon, Oct 07, 2002 at 04:01:41PM +0200, email@example.com wrote: > Then this question: what is against moving used blocks to fill up the free > blocks? The only reason I see is that it will cost time. Another problem is that you'd need to adjust the pointers to these moving blocks. Microsoft Windows 3 (and maybe its precursors) can do this for "unlocked" memory blocks. When an application reserves memory with LocalAlloc (or GlobalAlloc, there are two heaps: "near" and "far"), it obtains an identifier called a "handle". To obtain a pointer to the memory block, the application must invoke LocalLock (or GlobalLock). When the pointer is not going to be needed for a long time, the application should unlock the memory block. The block is deallocated by calling LocalFree or GlobalFree. (I hope that this explanation is correct; it has been ten years since I programmed Windows 3.0, and I have tried to avoid Microsoft systems since then.) I don't think that it is worth the trouble: it would be an additional burden for the programmers, and another source of bugs. Another instance where memory is "wasted" is when an application maintains a buffer for handling variable-sized items. In my experience, good performance is obtained by doubling the size of the buffer whenever the buffer is too small for reading an item, and by never shrinking the buffer. This practice is also good against memory fragmentation (where the heap is filled with unallocated blocks, each of which is smaller than the desired buffer size). Complicated optimizations should only be implemented when there is a problem. If the application spends 90% of its execution time in 10% of the code, it is best to concentrate to those 10% and leave the 90% alone, if you want to finish the program quickly. The same applies if 90% of the memory is used by data structures managed by 10% of the code: one should only optimize those data structures that are the bottleneck. Marko Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.4.