Re: Zero-size array as struct member
On Aug 21, 7:50 am, Juha Nieminen <nos...@thanks.invalid> wrote:
Goran Pusic <gor...@cse-semaphore.com> wrote:
[...]
Nope. The majority of that time is spent *allocating memory*.
If I change the above code to use a very fast memory
allocator, such ashttp://warp.povusers.org/FSBAllocator/so
that the declaration of 'someSet' becomes:
std::set<int, std::less<int>, FSBAllocator<int> > someSet;
then the running time drops down to about 2.5 seconds.
From the 10 seconds running time of the original program above over
7.5 seconds is spent solely on memory allocation and deallocation.
Maybe. Alternatively, it's spent because one allocator results
in better locality than the other, with less page faults.
That's quite a *lot*. (There are many reasons why this is so,
one of the major ones being that the default allocator is
thread-safe, which the FSBAllocator above isn't.)
'new' and 'delete' are significantly heavy operations.
Typically, yes, although some implementations (including VC++!)
do optimize them for "small" allocations---replacing the
allocator for the int's in a shared_ptr, for example, rarely
gains much, since the implementation already picks up the
"small" allocation, and uses a specialized strategy for it
(which isn't that heavy).
[...]
And even locality of reference is not a concern, because allocators
mostly do a good job of allocating blocks close in space if allocation
is close in time. E.g.
I'm not sure where he got this from. In my experience,
allocators do a good job in allocating similarly sized blocks
close together, but when the sizes are radically different, it
varies considerably.
--
James Kanze