[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Bubke Marco]

On October 17, 2015 19:22:55 Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Saturday 17 October 2015 08:06:33 Marc Mutz wrote:
>> > The word 'fanboys' disturbs me (I know you don't mean it that way) because
>> > there are no 'hard' numbers on how 'bad' the current situation really is.
>> > It would really be helpful to have an idea how 'real-world' applications
>> > suffer from the current implementation of QString. That would give a very
>> > good context to decide how Qt can help to leverage these problems.
>> 
>> If you want real-world numbers, follow the optimisations Milian did in moc. 
>> IIRC, he documented the speedup.They are not (all) string-related, but I
>> also don't claim that QStringView will single-handedly make your apps go
>> faster. I wrote about QList already. There's more where these topics came
>> from, but essentially they all boil down to: "minimise allocations".
>
> On the other hand, note how real world numbers show that QtGui and QtWidgets 
> consume a lot more CPU time than the combined time spent in malloc and QString 
> operations.
>
> Last time I profiled Qt Creator startup and parsing of projects, the two most 
> expensive calls in QtCore were qHash and the SHA1 calculator. The former I've 
> already fixed. The latter I was hoping that some colleagues would fix by 
> creating an optimised library[1] we'd use but they refused to add SHA1 support 
> to it.

Thiago, we will be using clang as the new code model and in my experiences it is quite slow so we have to hide the latency. This is not only clang but same parsing of the results too where we heavily use a QByteArray wrapper. If I have time I will try out QValArray but it is not so urgent. I think QtCreator is an example that string operations matter because every latency as you type is quite unpleasant.