Roll our own qUtf8Printable()?

Lubomir I. Ivanov neolit123 at gmail.com
Sun Feb 25 13:59:21 PST 2018


On 25 February 2018 at 23:40, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> On 25 February 2018 at 21:39, Berthold Stoeger
> <bstoeger at 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

* shouldn't

lubomir
--


More information about the subsurface mailing list