On 25 February 2018 at 21:39, Berthold Stoeger <bstoe...@mail.tuwien.ac.at> wrote: > Dear all, > > In many places, QStrings are converted to C-style strings with an expression > of the kind > s.toUf8().data() > > I have a patch replacing all of them with > qUtf8Printable(s) > > The idea is that - according to the documentation - this is equivalent to > s.toUtf8().constData() > > The latter should produce less machine code, because it doesn't have to check > whether the data of the temporary QByteArray is shared. Owing to the many > indirections in Qt's code, the compiler is not smart enough to understand that > in this case data() = constData(). > > Much to my surprise, qUtf8Printable() produced larger code. The reason is that > it is defined as a macro in <qglobal.h>: > > #ifndef qUtf8Printable > # define qUtf8Printable(string) QString(string).toUtf8().constData() > #endif > > It generates a temporary copy of the string! This looks like a defect to me. >
the compiler could be missing an optimization opportunity for the copy? maybe the inline version (118 bytes) produces simply better optimized code. have your tried with a different compiler and playing with -Oxx? > So what do you think about rolling our own helper function: > > inline const char *qstring2c(const QString &s) > { > return s.toUtf8().constData(); > } > > Some numbers (size of the .text segment): > const char *test(const QString &s) { return qUtf8Printable(s); } -> 267 bytes > const char *test(const QString &s) { return s.toUtf8().data(); } -> 236 bytes > const char *test(const QString &s) { return qstring2c(s); } -> 118 bytes > > That's a 50% size reduction per invocation. > my rule of thumb would be that we should reinvent the wheel for the sake of size or speed even. 1000 instances of the qUtf8Printable() macro would be 267 * 1000 and that's 267kb which isn't that much. at the same time nothing prevent's us from having this helper if we prefer it over the recommended method. lubomir -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface