> On 12 Jul 2015, at 16:58, Marc Mutz <marc.m...@kdab.com> wrote: > That's because your benchmark runs entirely in L1. > If you want to test containers of 10, 100, 1000 and 10000 elements each, then > make > - one run over 1×N containers of 10000 elements each, > - one run over 10×N containers of 1000 elements each, > - one run over 100×N containers of 100 elements each, > - one run over 1000×N containers of 10 elements each.
This is getting defensive, and quite frankly, a bit boring. The fact that half of the emails are from one author defending his absolute view with increasingly complex arguments suggests action points be taken and the debate be closed. Clearly Marc should write a /book/ about which tricks should be applied when writing high performance code. It’s non-trivial, and it really is no container’s role to be the sole solution to everything. There’s also no such book out there but clearly many “undocumented tricks” and pitfalls. We can’t add tables, and complex explanations, or dynamic forms where you input your sizes and types, to Qt docs to “help” people choose the right container. Complex docs == bad docs. Writing high performance code requires a touch of genius, and only needs to be applied to choice of algorithms at the highest level and only the most important loops at the lowest level. The performance of QList isn’t the prime focus of people writing normal code. Paint engine insides, for example, we make an effort not to allocate memory at all from begin to end. That sort of rules out most container classes out there. Suggested actions points: 1. Update Qt docs to indicate that careful planning, perhaps a pointer to Marc’s blog, this thread, and QVector docs, could be useful when writing performance critical code. I’m certain QList will be just a tiny chapter in Marc’s upcoming book but link to that chapter. 2. Analyze (again) when is the time to make Qt’s containers simple wrappers over those of stl and/or boost. Performance differences over equivalent classes with different APIs should be limited to the API differences themselves. Nothing else makes sense. 3. Marc, consider writing that book. It’s not a general book on Qt, because Qt is about writing code simple quick and easy with acceptable performance, not how to squeeze every cycle out of every part of your code. Andreas _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
