Topic: Dynamic allocation, -what's fastest?
Author: sabroe@daimi.aau.dk (Morten Sabroe Mortensen)
Date: 30 Aug 92 17:16:44 GMT Raw View
I'm wondering about making a data-structure, that can sort elements
real quick, -not "on the the run", but after all elements have been inserted!
Now, -quick-sort isn't that bad,- so I could just use a simpel array! Well,
I could, but then I need a limit on the number of elements, I can insert, and
that's not what I want! No, -I'm thinking about a dobble-linked list; it must
be possible to run quick-sort on that! No matter what's best, it's not that
part, I want you to respond to (but, -feel free to do so anyway!).
Now, for some reason I want to make a dobble-linked list of, say,
void-pointers! The usual way to do it, is to have one entry in the list
for each inserted element, right? Would such a structure eat less memory, and
,-which is, what I'm really after-, less time, if each entry in the list is
an array of some fixed size, -f.ex. big enough to hold 500 elements? WHY DO
I THINK, that it could be, that it's a good strategy to make a list of arrays
of fixed size? Well, how expensive is 'new' and 'delete' really? Would it be
better to allocate many small memory-blocks, or just a few big memory-blocks?
I'm not surprised, if it's equal expensive to allocate blocks of different
sizes! DOES ANYONE KNOW ANYTHING ABOUT HOW EXPENSIVE 'NEW' AND 'DELETE'
REALLY ARE? WOULD I GAIN ANYTHING, IF I DON'T USE 'NEW' AND 'DELETE' MORE
THAN ABSOLUTELY NESSESARY?
What I want to do with the linked list, is insert a lot of elements,
then sort it all, traverse all elements, delete it all (or, if I get better
performance, delete while traversing), and then start all over with a new set
of elements! It would not give me too much trouble to program these two
different strategies, and then run a test on both of them, BUT I really want
to know about this in teory first!
If anyone knows how time-consuming 'new' and 'delete' are, please
respond! I done through e-mail, I might or might not post a summary!
-- Morten S. M.