> On Feb 10, 2015, at 10:51 AM, Marc Mutz <marc.m...@kdab.com> wrote: > > On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote: >>> On Feb 9, 2015, at 3:40 PM, Marc Mutz <marc.m...@kdab.com> wrote: >>> >>> On Monday 09 February 2015 09:54:12 Smith Martin wrote: >>>> This is the kind of thing we should add to the documentation, but can >>>> you elaborate? I mean, illustrate the meaning of "locality of >>>> reference," "wildly mixing insertions, lookups, and removals," and >>>> "batch updates and separate them from lookups, time-wise." >>> >>> There is a book, Effective STL, and an online paper, "What every >>> programmer needs to know about memory". I don't think that it's the job >>> of the Qt docs to explain "what every programmer needs to know about >>> memory", because it is not specific to Qt. >>> >>> The Qt documentation also doesn't give many details on Unicode. It's >>> assumed that people using it know the basics. >>> >>> You will also not find in the Qt docs that signed integer overflow is >>> undefined behaviour. >>> >>> The Qt docs are not a CS text book :) >> >> That QMap is implemented based on a RB tree is mentioned in a single >> sentence in the beginning of the description of the class, which is the >> sentence that nobody ever reads (because it tends to contain useful >> information like "The QList class is a template class that provides >> lists.”). >> >> It is followed by a short (but longer) comparison between QMap and QHash, >> which in turn is linked to a relatively long section that compares the >> complexity of Qt’s different containers. So, fact is that the Qt docs *do* >> explain more than “QMap is a RB tree” (and I think that is good so). And >> since they talk a lot about algorithmic complexity, it would probably be >> useful to mention a few other things that concern performance differences >> as well. In ~5 sentences. I really can’t see how that could hurt. >> >> Actually you sounded like you’d like to educate people about this also >> “outside of CS courses” (by sending them to their manager etc), so do you >> have a different, realistic proposal? > > The topic of this thread is guidelines for Qt code, not code using Qt.
Qt code is code using Qt. Qt developers are Qt users. Qt developers (read: contributors) also read Qt documentation to find out which data structures to use for solving which problem. > We > don't want to impose writing Q_DECL_CONSTEXPR everywhere possible for users > of > Qt. Likewise, if they want to use QMap, then that's fine. A profiler will > tell > them if they made a mistake that matters. > > The situation is different for Qt code: Actually not much, since there are many other libraries than Qt out there that use Qt and therefore must also “optimize for everything”. > Consider a recent example: QString::multiArg(). It used a QMap. Now it uses a > QVarLengthArray (introduced in 7b5ba56b0ab55fcaf79fbf9aad70bf767c938e15). A > very naïve benchmark (I'm allowed to say that, it was my choice). was sped up > by 30%. The naïviteé in the benchmark is that this includes repeated > allocation of a handful of QString arguments from short (C) string literals > each time through the loop, which probably dominates the result. > > We don't know what Qt is being used for, so we need to optimize everything. > One user surely will run multiArg() in a tight loop and that will dominate > his > runtime. As every C++ library that's any good, we cannot be sloppy when it > comes to efficiency. > > So, no, I don't think we should discuss everthing ever written about C++ > efficiency in the Qt docs. Nobody has claimed that we should. > But we need to point it out to each other in code > reviews and become better at not writing sloppy code. Nobody has claimed that we shouldn’t. Discussing in the documentation which classes are best used in which use cases, might reduce the need to educate people over and over again in code reviews though. And reviews could be abbreviated to “don’t use QMap in this case, read <link to Qt documentation>”, instead of discussing the same thing over and over again. > IOW: We need to start thinking about our algorithms and data structures > again[1], but this time in the new world of caches and multithreading where > the only fast data structure is an array.[2] > > Thanks, > Marc > > [1] http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic- > Computation/dp/0130224189 > > [2] http://vimeo.com/97337258 > > -- > Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-Independent Software Solutions -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
