on 03.05.2010 at 21:37 Stewart, Robert wrote :
DE wrote:
i suddenly have remebered a rule on optimization: measure, then optimize in other words: find a bottleneck and only then optimize the code causing it
That's exactly what Chad did. That's why he added COW. With the addition of move semantics, there's reason to think it shouldn't be needed.
in this thread things look the other way around you guys make a guess and ask to change/optimize the code using that guess as the basis sorry, i consider it wrong
There is nothing wrong with trying to poke holes in a design or implementation. From experience, we know that COW is usually a pessimization rather than an optimization in MT code, so it is usually avoided altogether for simplicity. Its need raises red flags. When the tests suggest that the library is truly faster with COW, we're a little skeptical and want to understand why. This is the scientific method in action.
in fact it must be like this: - i use it in a <usecase>, i profiled it and found a bottleneck in the following piece of code...
otherwise there is a big chance we are wasting each others time making guesses and arguing about implementation details because optimizations born from that may be worthless
I disagree. The COW issue will be raised during review. Chad needs to be ready to defend its use then. Having done so now means he can explain it in the docs and avoid such discussions during the review.
i agree with almost all you've just said however chad not only stated that his cow is faster (a pun intended) but also provided numbers (test results -- read "the proof") so that's you who must prove the cow is slower than whatsoever or misapplied, not chad -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out