From: Corrado Zoccolo (czoccolo_at_[hidden])
Date: 2007-12-04 03:29:45
On Dec 4, 2007 5:57 AM, Chuck Bear <chuck_at_[hidden]> wrote:
> With regard to (b) below, I think you should proceed empirically. However
> I can't resist the temptation to speculate about the performance of, at
> least, the gcc implementation of std::string, in different implementations
> of a load() method:
> 1. I can't imagine that the temp std::string implementation would be a
> disaster, because of the character ref counting. It means you'd create the
> chars for the temp string, fill them in, and then transfer the reference
> over to the real string (without further adjustment of the characters). I
> do think that the reference counts are done with fancy atomic operations, so
> there is a bit of memory-synchronizing or bus locking going on here (in my
> patch) that wasn't in the 1.34 implementation.
> 2. I have to imagine that the typical case is that load() is loading into
> an empty string. Also I suspect that "is a string empty" can be established
> very cheaply. So if my suggestion is too slow, you can do what I've
> outlined only if the string to be loaded was non-empty when passed in.
This atomic operations can be quite heavy on modern hardware. For small
strings, it costs as much as an allocation on a P4.
You can improve things by swapping the string instead of using assignment.
template<class Archive, class Elem, class Tr>
-basic_binary_iprimitive<Archive, Elem, Tr>::load(std::string & s)
+basic_binary_iprimitive<Archive, Elem, Tr>::load(std::string & res_s)
+ std::string s;
// borland de-allocator fixup
@@ -96,6 +97,9 @@
// note breaking a rule here - could be a problem on some platform
load_binary(const_cast<char *>(s.data()), l);
+ // Respect other references to the chars by assigning result string
This will avoid the atomic operations, but will still cost one allocation
and one deallocation more than initial solution.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk