kcalc > KCalcButton::paintEvent mallocs more than 80 MB per minute

[Nicolas Fella]

On 5/30/22 04:35, Marius P wrote:
> Hello,
>
> Would an improvement for the issue below. Constitute material for the
> KDE Eco initiative?
> If so, I am a senior C++ developer. I do not know Qt. I have more than
> 2 hours per week to dedicate to the issue below. I will need help.
>
> The ideal situation would be to not do custom painting.
>
> Technical details:
>
> As per
> https://blogs.gnome.org/chergert/2020/03/15/how-to-use-sysprof-to-part-ii/
> chapter "Reducing Memory Allocations". kcalc in
> https://invent.kde.org/utilities/kcalc/-/blob/master/kcalc_button.cpp#L133
> for each button, does custom painting. mallocs e.g. in QTextDocument
> ctor and in QTextDocument::setHtml(). The button's custom painting
> method uses HTML mainly for center aligning/justifying text.
>
>     ALLOCATED      TOTAL    FUNCTION
> [   81.1 MiB] [  69.04%]  KCalcButton::paintEvent(QPaintEvent*)
> [   23.7 MiB] [  20.20%]  QTextDocument::QTextDocument(QObject*)
> [   15.7 MiB] [  13.35%]  QTextDocument::setHtml(QString const&)
> [   12.0 MiB] [  10.21%]  QTextDocument::size() const
> [   10.3 MiB] [   8.74%]  In file
> /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/breeze.so
> [    6.6 MiB] [   5.59%]  QTextDocumentLayout::draw(QPainter*,
> QAbstractTextDocumentLayout::PaintContext const&)
>
> Thanks.

Hi,

some pointers on how to approach this/optimization in general:

0. Ask yourself whether optimizing this is worth the time. For a
calculator button I'd tend to say no, but for the sake of education it
may still be worth pursuing

1. Your instinct to drop the custom painting is good, but you need to
confirm that this will lead to good results before doing anything. I'd
suggest to remove the custom paintEvent function (and thus use the
standard paintEvent) and re-measure. If that doesn't make a significant
difference you're on the wrong track

2. If the standard paintEvent turns out to be faster you'd need to look
for how to make it do all the things the old code did, i.e. try to make
all the font/color/etc handling work using only QPushButton's API

3. If the custom paintEvent is still needed then it may make sense to
e.g. cache the QTextDocument instances instead of recreating them. Here
again, measure everything instead of jumping to conclusions.

4. I have no experience with sysprof, but I can recommend
https://invent.kde.org/sdk/heaptrack for this kind of work

Cheers

Nicolas