What s the Fuss About?

I l @ ve RuBoard

What's the Fuss About?

The point of this appendix is that some widely used library optimizations are effective in single-threaded mode, but can actually degrade performance if the library is built for possible multithreaded use. I'm talking about common and popular optimizations that you may be using already, even if you don't know it, because they're present deep inside many popular vendors ' libraries.

Here's more bad news: The performance impact is often severe, far heavier than it needs to be, even in some of today's most popular commercial libraries. Why? Because there's often more than one way to make code thread-safe, and some library writers pick methods that work all the time but aren't the most efficient for their particular situation. Certain popular libraries still use general-purpose constructs, such as mutexes , when more efficient alternatives would do. It makes a big difference.

And here's the worst news of all: Earlier, I wrote, "if the library is built for possible multithreaded use." This means the degradation can affect you even if your program happens to be single-threaded.

In this discussion, we'll consider again one type of optimization that is often a false optimization, but is commonly found in commercial libraries. I'll also show an easy way to detect the performance hit, if any, so you can check whether you're affected by similar hidden pitfalls in the libraries you're using now. If you are affected, you'll also have the information you need to report the situation to your library vendor, so they can correct the problem.

I'm going to illustrate the general problem with a specific example ”the Optimized::String class developed in Items 15 and 16, which uses the copy-on-write (COW) optimization. But please note:

  • COW isn't the only culprit. Everything I'll discuss applies to any transparentoptimization in which two or more objects can share information or state behind the scenes, where calling code can't see. This includes, but is not limited to, shared-implementation or lazy-copy optimizations such as COW.

  • Strings aren't the only culprit. Optimizations like these can and have been used for many expensive-to-copy data structures, including collections and containers.

Note that although our code happens to be written in C++, this discussion applies to code written in any language. One reason I'm writing about this topic is that standard C++ string s have acquired an undeserved "slow and inefficient" reputation in some circles. True, there certainly are needlessly inefficient implementations of C++'s string facility out there on the market today. But I want to emphasize the "needlessly" part, point out that there are high-quality implementations too, and show you how to tell them apart so that you can avoid the former.

I l @ ve RuBoard


More Exceptional C++
More Exceptional C++: 40 New Engineering Puzzles, Programming Problems, and Solutions
ISBN: 020170434X
EAN: 2147483647
Year: 2001
Pages: 118
Authors: Herb Sutter

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net