Optimized C++: Proven Techniques for Heightened Performance

A lot of the concepts don't have enough support or their support is not concrete enough. For example, the author describes the cost of function calls, including the hidden pointer to the "this" argument for member function calls that must be written to the stack or a register. For that reason, he encourages the use of static functions were possible. To me that's not enough of an explanation. I would have listed the number of registers available, including a discussion of how it's 32/64 bit and OS-dependent: 32-bit always pass parameters on the stack, 64-bit Windows passes the first four parameters in registers and 64-bit linux/BSD/MacOS pass 14 in registers (six of which can be pointers). -- Without this level of explanation, I found myself questioning the validity of some of the other proposed optimizations.A few concepts I was hoping for are missing, including vectorization (SSE, AVX), which is mentioned only in passing; more depth to floating point arithmetic; better discussion of memory and cache access patterns (the handling of the CPU cache in particular is so vague that there's no takeaway message that I could apply to my code); ...Meanwhile, there's an excessive amount of time spent on a handful of topics, including timers (why are sundials and grandfather clocks given full paragraphs?) and, as others have said, the C++ language itself.I was hoping this book would be a reference guide once I'd finished reading it, but a lot of the material wasn't quite concrete enough for it to be useful. I would highly recommend reading Agner's manuals instead if you have knowledge of C++ already. In some places they're a little bit dated but still solid and very much grounded in computer architecture. (Do a search, they're free online.)

Best book I've read on C++ since the Scott Meyers canon. It is well written and PACKED with technical knowledge. Clearly, Guntheroth is a seasoned developer who has done a good job of selecting the pertinent items about optimization and left out the mundane from this book. As an embedded C++ developer, the topics are right on point, well discussed, and thoroughly explained. This book goes deep and is not for the faint of heart. I would recommend this book to those who have already read Meyers and Stroustrup books and I would recommend reading this BEFORE reading Alexandrescu.

It's not bad but it's one of those books you read and at the end don't fully understand what you learned. The best example of this phenomenon is reading a dictionary - you read entire dictionary but still don't have a clue how to speak the language. This happens when connections between concepts are not elucidated enough.

I would call this book “Optimized C++ for beginners from beginner. “ There are 2 main problems in this book.1. It is really for people who does not know C++. Literally half of the book is explanation what is std::string and” don’t do too much in the loop”.2. It seems to me author himself does not understand relatively basic things about C++ optimization ( e.g. why binary search on sorted array could be faster than hash map ). Some statement such as “always move declaration of a variable out of the loop” is just incorrect.Advise for beginners – don’t buy this book. Learn from experts: Scott Meyers, Nicolai M. Josuttis, Antony Williams, Andrei Alexandrescu, Herb Sutter …

Useful guidelines, check-list for intermediate C++ programmer!

While reading this book, I got a feeling that there IS real experience behind it, and experience is the only thing which matters for such dark magic thing as optimization. In particular, emphasis on memory accesses being expensive is EXTREMELY important in real world, and is well-covered in the book, kudos! Also, the book doesn't degenerate into a messy unstructured list of unrelated techniques and at least tries to put it into perspective.OTOH, sometimes this real experience is a bit, well, stale. For example, for measuring time intervals the book states that "on PCs, the fastest tick counters available have 100-nanosecond resolution" - which isn't true even for Windows which corresponding section heavily leans to (there is RDTSC instruction with ~1ns resolution for about 20 years now on all what can be named PC). In another example, in the whole chapter dedicated to strings I didn't find a reference to Small String Optimization (SSO), which is a reality for 5+ years now, and which changes performance analysis significantly. Advice "perform I/O in a separate thread" is also outdated in the modern days of generally-better-performing async I/O (at the very least, async I/O should be mentioned in this context).Overall, I'd give this book 3.5 stars, but there is no such option - and given that books with real-world experience are rare, I decided to round it up rather than down.

I bought this book in rough cut form and watched it develop. The book is unusual and good IMHO, it has some really great analyses of container algorithm performance comparison and provides good specific guidance on algorithm and container use. It has been a joy to read and learn from. I liked the separation of discussion of optimizing data structures versus optimizing your use of containers. Chapter 6,7,8 are wonderful educating reads.

It`s a very good book in a technical aspect, but the way it was written make it harder to understand for people who are used to read academic books.

Unfortunately, this book suffers from a few significant problems.First, the author writes extensively (probably about half of the book in total) on basic C++ concepts that most readers should already know and/or concepts that are irrelevant to the topic of the book.Second, when the author tries to provide potentially useful information, he discusses the topic in an inadequate way that is likely to leave readers scratching their heads in confusion.Third, more than a few times the author wrote something that I knew to be incorrect or misleading.Here are some examples of those second and third problems...On pages 84-85, the author advocates the use of std::stringstream, but neglects to mention that this class performs lots of work in its constructor (apparently something to do with locales). I once obtained a significant optimisation in an application by removing as many instances of stringsteam as I could.On page 97, the author advocates use of hash tables but neglects to mention that the heap allocation used in most hash table implementations is likely to increase cache misses (and hence reduce performance). He neglects to mention that there are some implementations of hash tables that use a large block of contiguous memory to be more cache friendly. (Do an Internet search for "flat hashmap" if you are interested in efficient hash tables.) The author mentions that a hash table lookup is O(1) in the common case and O(N) in the worst case, but never mentions the possibility of using a DFA, which is always O(1) lookup. Put simply, a DFA can be faster than a hash table, and this contradicts the author's claim that hash tables provide the fastest table lookup mechanism. The discussion on page 97 about hash tables would have benefited from mentioning the possibility of perfect hashes, but readers have to wait more than 100 pages (until page 224) for a mention of this.On pages 123-124, the author mentions the possibility of storing a balanced binary tree in a contiguous array rather than in fragmented heap-allocated memory. This is a potentially useful thing to know but, unfortunately, the discussion of this topic is too superficial to be useful. In addition, he conflates two different opportunities for optimisation---(a) using a continuous array to avoid fragmented heap-allocated memory, and (b) using implicitly computed pointers/indexes rather than explicit pointers to parent/child nodes---into a single discussion and gives the incorrect impression that you must combine both opportunities together.On page 150, the author mentions the possibility of iterating over an array backwards (that is, from length-1 to 0) rather than forwards (from 0 to length-1), but he neglects to warn that iterating backwards might be slower due to some CPUs implementing a forwards-looking-only cache prefetching mechanism. On my Intel-based laptop, iterating backwards over a multi MB array takes 25% more time than iterating forwards.On pages 233-234, the author uses low-resolution timers to do a high-resolution performance test. The author tries to explain why this should work, but the explanation is too superficial and left me dubious.On page 245, the author claims that, in most cases, the relative performance of two apps/algorithms when compiling in debug mode is similar to the relative performance when compiling in release/optimised mode. I was shocked at the author's naivety when I read this claim.In summary, the book provides very little useful insight but lots of waffle and too much incorrect/bad advice to be recommended. Part-way through reading this book, I found a much better book called "Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms". You can find a free PDF of that book with an Internet search. It contains about half the pages and 10 times more insight than "Optimized C++".

Really liking this book. Goes in to great detail. Sometimes a little too much about very specific things, hence only 4 stars, but these areas are easy to skip over. Should be required reading for all C++ coders. Does include the latest C++14 alterations.

I was hoping for a book tackling mostly C++-specific issues, and in depth. It turns out the book has a lot of generic advice, such as "optimize hot loops" or "use a thread pool rather than launch a new thread every time".There is some interesting discussion of some C++-specific aspects, but not often in a very thorough or consistent manner. In the chapter about standard containers, the author gives a bunch of performance figures measured with some benchmark of his own, but the source code for the benchmark is unavailable, so you cannot try with your own compiler and standard library. Knowing that this or that has lackluster performance on Visual Studio 2015 doesn't help much if I'm targetting gcc 6 with the GNU libstdc++ on Linux.In the part about memory management, there is this very vague statement "I have heard a rumor that both Windows and Linux have recently raised their game with state-of-the-art memory managers". Well... ok, you've heard a rumor, but you're writing and selling a book about optimized C++, so perhaps you should have gone and validate what the rumor says? I don't buy a specialized, technical book to learn about unconfirmed rumors!As a more minor issue, I'm surprised that the author spends time discussing pre-C++11 idioms. This, in a book published in 2016.I'm not a veteran C++ programmer, yet I feel I learnt too little by reading this book.

L'autore tratta alcuni argomenti in maniera fin troppo banale. Ci sono fin troppi esempi per sistemi windows and qualche raro cenno a sistemi unix. Sul web si trovano molte piú informazioni utili.