Mail Archives: djgpp-workers/1997/11/09/17:40:07
> The code _is_absolutely_free_. No GPL, just free.
> The docs make me think that it hes been used in a wide range of
> applications and thoroughly tested. It looks as if the author knew
> what he is doing. The only reason I could think of not using the
> package from a stabilty point of view is that sbrk() under DJGPP may
> behave quite differently from the UNIX behavior.
So, with more testing (like a GCC built with it re-compiling itself in
about the same time, and tests on different platforms) DJ may accept it.
Heck, he may take it right now anyway ...
> In terms of speed, it tends to be slower than the libc malloc, if one
> looks only at the allocator/deallocator. The factor is about 2, not
> as SET reported, 7. Things change when not only malloc but also
> realloc is used, because this sometimes means touching the data as
> well. Also, when using memset() to touch the data, the libc malloc is
> never faster.
One package is almost never best for everything. If the new package
saves memory it may delay the onset of paging, which would be a huge
time savings. It may be slower for lots of small allocations/frees.
The default malloc/realloc is great for lots of incremental reallocs,
since they usually don't do anything except return the same pointer
unless you jumped a power of 2.
I would tend to think a marginally slower package which pages less and
fails later would be a better default choice. But I am very conservative
about changing working things also...
> Swapping was avoided. Eli proposed to set the CWSDPMI swap
> file to a nonexistent drive to figure out when swapping occurs. Can't
> the same be archived by just setting __CRT0_LOCK_MEMORY?
Not exactly. CWSDPMI does a lazy allocation, which means if you never
touch the page it never consumes memory or swap space. If you lock the
memory, even pages not touched get forced into memory. The lock memory
behavior probably better shows the behavior under other DPMI providers.
So, to a small extent CWSDPMI is tuned to help out the default malloc
behavior on large requests speed wise.
> One last thing, the tests produce some files with blocksize-time
> columns, is it OK to post them here or will I get beaten to death?
> There a some 300 lines of figures...
You obviously believe this new package is an improvement, so continue to
push for change! I don't need the figures to be convinced one way or the
other. Speed isn't everything - or some of the changes which have slowed
down the libc wouldn't have been accepted.
I'm always a proponent of more testing. Does GCC compile big files faster
in limited memory with the new allocator? Would anyone notice a difference
in a typical algorithm? Have fun!
- Raw text -