Mail Archives: djgpp-workers/2002/03/15/21:24:21
I have shipped the complete package to DJ and asked him to mount
it for all to try and criticize. It appears to be bug free, and I
am not ashamed of the speed. As I posted before the O(Nsquare)
free action has been reduced to O(N). The compiled module is 2528
bytes, or 0x9e0, long and can probably be reduced. The makefile
creates debug, profiling, and release modules together with a
large set of tests.
The package has been written with clarity in mind. On review, I
find that it would be relatively easy to reduce the per block
overhead to 16 bytes from the present 24, at the cost of the
accuracy of some validity tests. This would also prevent the
application from ever doing a "malloc(0)", which is illegal
anyhow, but is now handled. However it would make changing
alignment from 8 to 16 totally trivial.
I also find that one particular testing sequence triggers the use
of memmove in realloc quite often. The result is that the system
spent over 50% of its time in __dj_movedata for this particular
test. This is because realloc attempts to use adjacent free
blocks, and this could be avoided by simply forbidding the use of
free blocks adjacent below. (memcpy simply becomes a rep movsl
instruction). Such a change would probably increase memory
fragmentation.
Is the reduction of memory overhead actually important today?
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:uce AT ftc DOT gov (for spambots to harvest)
- Raw text -