Re: What's the boost pool allocator good for?
On Jul 10, 10:40 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
James Kanze wrote:
When I change to the version of the list which uses the boost
pool allocator and do the same thing, the running time is a
whopping 59 seconds. That's approximately 1800 times slower.
Did you expect anything different?
Certainly. What sense does it make to use an allocator which
makes allocation almost 2000 times slower? It makes no sense
whatsoever.
You use a non-standard allocator because you need different
semantics. If you need those semantics, it doesn't matter what
the speed, since the program won't be correct without them.
If the semantics are correct with the standard allocator, then
that's what you should be using.
[...]
The purpose of the allocator parameter is not for a possible
optimization, but to support different semantics, and normally,
I would expect any custom allocator to be slower than the
standard allocator, at least if the library author has done a
good job.
Why do you expect that?
Because if it were faster, then the implementors of the standard
library would have used the same algorithms.
I can think of four reasons to use a custom allocator:
1) The allocator is way faster than the default allocator.
2) The allocator consumes considerably less memory than the default
allocator.
3) The allocator performs GC or other type of safety checks (which would
be mostly irrelevant with the STL containers, but anyways).
4) The allocator does something exotic, such as use a file or a network
connection as memory, or something along those lines.
The only possible reason for using a non-standard allocator with
the STL should be the last. Unless the implementor has not done
his job correctly.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34