On Mon, October 23, 2006 15:25, Peter Dimov wrote:
Ovanes Markarian wrote:
Now with default macros used, shared_ptr is about 10% slower. If I use the quick allocator the speed is only 8% slower. If I enable both macros (single-threaded and quick-allocator) shared_ptr is quicker as an implementation without shared_ptr. My question now would be if you plan or it is already possible to have a policy for specifying Threading and Allocator?
You can override the allocator used for the internal allocation of the control block by using the shared_ptr constructor taking three arguments (it's a relatively new feature) but judging by the numbers, there isn't much point in doing so, as the default allocator is good enough. 2% isn't a significant difference and it may well be the case that the default could be faster in real code.
Currently there is no way to specify a threading policy.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Well, I have messages consisting from multiple optional smaller object instances. I would like to try the approach described in A. Alexandrescu's Modern C++ Design: Small Object Allocator. Unfortunately I can not use it directly from Loki lib, since it does not have interface described in c++ standard for std::allocator. I think 2% in such a small piece of software, which constists let's say from ca. 7 such small pieces can turn out into a 14% perfromance increase if a good allocation strategy can be found. With Kind Regards, Ovanes Markarian