aaronpuchert added a comment.
In https://phabricator.kde.org/D9824#192793, @rjvbb wrote: > If real-world impact is in the order of a highly significant but millisecond-order reduction of reaction time to file change there may be little reason to commit this improvement now (and then risk forgetting about the rest again). My hunch is that it could be more effective then to keep this change pending and use it as a motivation to work on a more complete overhaul of the class. You know how they say, “perfect is the enemy of good.” Also we know at least one person that isn't going to forget about this, don't we? To keep an improvement — and you don't seem to dispute that it is an improvement — pending as “motivation to work on a more complete overhaul” is an argument I can't follow. I guess this is what Uncle Bob calls the Grand Redesign in the Sky <http://www.informit.com/articles/article.aspx?p=1235624&seqNum=3>. In https://phabricator.kde.org/D9824#191203, @dfaure wrote: > I'm 100% sure the same rules applies, because the "limitations" of operator[] come from C++ and therefore apply to all associative containers. The limitation is that with `operator[]` followed by an assignment the associated value is first value-initialized (here zero-initialized), before later the actual value is written. Since the value has type `Entry*`, “a hair faster” is quite accurate. I doubt this is even measurable, taking into account the cost of allocation, computing the hash value, and possible cache misses, that are associated with adding a new element. I'm not saying we shouldn't use `insert`, but it's probably a micro-optimization. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D9824 To: mwolff, dfaure, rjvbb, #kdevelop Cc: aaronpuchert, bcooksley, zimmerman, markg, #frameworks
