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, ruud.baltissen@abp.nl 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.