[Bug libstdc++/13823] Significant performance issue with std::map on multiple threads on dual processor - possibly default allocator

[rittle at latour dot rsch dot comm dot mot dot com]

------- Additional Comments From rittle at latour dot rsch dot comm dot mot dot com  2004-01-23 04:14 -------
Subject: Re:  Significant performance issue with std::map on
	multiple threads on dual processor - possibly default allocator


> I'm no expert here, but perhaps it would still be best to have an outer loop
> in the calc function - say 5 or 10 iterations.  That may exercise the
> allocator a bit more, repeatedly allocating and deallocating from the pool.

OK, added to performance test case I'm adding to libstdc++-v3.

> As an aside - I didn't know an array could have a variable as its size.
> Stroustrup's C++PLv3 says "The number of elements of the array, the array
> bound, must be a constant expression".  But I see it compiles and works with
> gcc!

OK, you got me.  Add -pedantic to see g++ fail the test case, as I
updated it.  This is a long-standing gcc extension.

> (btw I was aware of the misuse :)

OK, no problem.  Just an FYI to those that follow the thread later.

Thanks for the PR,
Loren


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13823