Optimal replacing windowTitle with new QString

RedSoft

I am writing Qt-based application and need to update MainWindow Title each time a user changes an active document. The title is build as follows: "AppName - <DocumentName>". If I understand correctly, when I set new title via QWidget::setWindowTitle method, the old QString title is deallocated and new one is set. But it can result a lot of malloc/free calls during my application executing. Is it possible to preallocate QString for title with some spare for long DocumentName string, and after 1st setWindowTitle to get a reference (not a copy) to this new title string in order then only to replace the needed part in existent title, and then somehow force this updated title to be refreshed?

mrjj

Hi
QString is implicitly shared - so i would not worry about memory fragmentation
setting the Windows title.
https://doc.qt.io/qt-5/implicit-sharing.html

However, the final setting of the title via the OS, will copy/allocate so
I think there is no way to make this very effective.
However, unless its an extremely small board you run app on,
the title setting should not be an issue.

RedSoft

@mrjj Implicit sharing works when several clients own one shared QString data for reading purpose, writing should also update all. But in the described by me case, setWindowTitle caller allocates new string in his own memory (e.g. stack) and then passes it to the Qt engine. I do not mean the possible resulted overhead in the OS underlying mechanism, cannot eliminate it. But if Qt keeps some QString copy for each windowTitle, I would like reuse its buffer each time I update the title.

mrjj

Hi
It seems not possible to have access to that buffer as its part of private d class.
https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html

QString QWidget::windowTitle() const
{
    Q_D(const QWidget);
    if (d->extra && d->extra->topextra) {
        if (!d->extra->topextra->caption.isEmpty())
            return d->extra->topextra->caption;
        if (!d->extra->topextra->filePath.isEmpty())
            return QFileInfo(d->extra->topextra->filePath).fileName() + QLatin1String("[*]");
    }
    return QString();
}

VRonin

Donald Knuth said

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

aha_1980

Full ack to @VRonin.

@redsoft: if you set the window title 1000 times per second(*), it may be a problem. But if you do, you already have a bigger one.

If you set the title, let's say every 2 seconds, there are much more other memory allocations/deallocations already done in background, so your's really don't matter.

(*) And even if you do, it has to be proven, that malloc is really the limiting factor in that case.

RedSoft

@aha_1980 In general I can agree with you and @VRonin. But you should understand, that if any new student starts his practice with such "allowance", we can expect from such new programmer in the future many "surprises" :) . And we are responsible for them :)
Especially, concerning my situation, it is interesting to me because of in the nearest future I want to port my app to some resource restricted platform.

aha_1980

@RedSoft again, you are speculating. Have you proved that this task is a problem? If not, why do you worry?

kshegunov

@RedSoft said in Optimal replacing windowTitle with new QString:

But you should understand, that if any new student starts his practice with such "allowance", we can expect from such new programmer in the future many "surprises"

If you start building a house, is your first concern whether the concrete, you haven't yet poured and you're not going to for a long time, has the right consistency? I find that hard to believe. You don't start designing the window before you have a wall to put it in, you don't have a wall before you have a foundation to place it on.

The same principle applies. When you start considering a program you should first consider the big-picture, the major components - the data structures, the algorithms, the way it's going to be used and you design based on that. After you are satisfied with all this then you may start worrying about the minor details. The point of @VRonin's quote is not to forgo optimization, but to choose your battles. If I have a codepath that's executed once and it consists of 1% of the CPU time spend in the program if I speed it up 10 times I shed 0.9% of the CPU time. If I have a codepath executed multiple times which eats up 10% of the CPU time, if I can speed that up only twice I have accomplished 5% faster total execution.
So is it worth to invest time in the first case before solving the second one (and that is all assuming it's at all necessary)?