[computer-go] Language War!

[Darren Cook]

>> STL is slow for the same reason that java is: dynamic memory
>> allocations. I usually use an STL container when writing and testing
>> code, then if profiling shows it is a bottleneck I write a custom
>> replacement class which avoids memory allocations (or uses a custom
>> memory pool).
> 
> Don't forget that one of the template parameters is a memory allocator.
>  If you want to go with a non-dynamic memory pool with pre-initialized
> objects or whatever, you can do that (and still use standard STL)

Have you ever got this to work (as in stuck with STL containers and got
a measurable performance increase from switching to a custom allocator)?
I haven't (well I couldn't even get my code to compile before I gave up
and wrote my own custom solution). See also items 10 and 11 of Effective
STL. It starts: "Allocators are weird..." :-)

Darren