StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Well there are definitely known problems regarding the performance of strings and other containers. Most of them have to do with temporaries and unnecessary copies. </p> <p>It's not too hard to use it right, but it's also quite easy to Do It Wrong. For example, if you see your code accepting strings by value where you don't need a modifiable parameter, you Do It Wrong:</p> <pre><code>// you do it wrong void setMember(string a) { this->a = a; // better: swap(this->a, a); } </code></pre> <p>You better had taken that by const reference or done a swap operation inside, instead of yet another copy. Performance penalty increases for a vector or list in that case. However, you are right definitely that there are known problems. For example in this:</p> <pre><code>// let's add a Foo into the vector v.push_back(Foo(a, b)); </code></pre> <p>We are creating one temporary <code>Foo</code> just to add a new <code>Foo</code> into our vector. In a manual solution, that might create the <code>Foo</code> directly into the vector. And if the vector reaches its capacity limit, it has to reallocate a larger memory buffer for its elements. What does it do? It copies each element separately to their new place using their copy constructor. A manual solution might behave more intelligent if it knows the type of the elements before-hand. </p> <p>Another common problem is introduced temporaries. Have a look at this</p> <pre><code>string a = b + c + e; </code></pre> <p>There are loads of temporaries created, which you might avoid in a custom solution that you actually optimize onto performance. Back then, the interface of <code>std::string</code> was designed to be copy-on-write friendly. However, with threads becoming more popular, transparent copy on write strings have problems keeping their state consistent. Recent implementations tend to avoid copy on write strings and instead apply other tricks where appropriate. </p> <p>Most of those problems are solved however for the next version of the Standard. For example instead of <code>push_back</code>, you can use <code>emplace_back</code> to directly create a <code>Foo</code> into your vector</p> <pre><code>v.emplace_back(a, b); </code></pre> <p>And instead of creating copies in a concatenation above, <code>std::string</code> will recognize when it concatenates temporaries and optimize for those cases. Reallocation will also avoid making copies, but will move elements where appropriate to their new places. </p> <p>For an excellent read, consider <a href="http://www.ddj.com/database/184403855" rel="noreferrer">Move Constructors</a> by Andrei Alexandrescu.</p> <p>Sometimes, however, comparisons also tend to be unfair. Standard containers have to support the features they have to support. For example if your container does not keep map element references valid while adding/removing elements from your map, then comparing your "faster" map to the standard map can become unfair, because the standard map has to ensure that elements keep being valid. That was just an example, of course, and there are many such cases that you have to keep in mind when stating "my container is faster than standard ones!!!". </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload