the profile is becoming a bit of a cpu hog

[Lubomir I. Ivanov]

On 8 January 2015 at 01:12, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>
>
> On Wed, Jan 7, 2015 at 9:05 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
>>
>> On 8 January 2015 at 00:10, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>> >
>> >
>> > On Wed, Jan 7, 2015 at 7:10 PM, Lubomir I. Ivanov <neolit123 at gmail.com>
>> > wrote:
>> >>
>> >> win64, dual core cpu
>> >>
>> >> general performance drops are observed in both official binaries and
>> >> my local debug build.
>> >> of course we can wait until *actual* users complain, instead of me.
>> >> just a report, as i don't have time to fix any of that ATM. perhaps
>> >> later this month...
>> >>
>> >> i guess this is mostly in Tomaz' field.
>> >>
>> >> with the recent addition of the mean depth line and text, i've noticed
>> >> further increase of cpu usage when hovering the profile. so i've
>> >> started "profiling the profile" to see what are the main causes for
>> >> the high cpu usage 30%.
>> >>
>> >> i've realized it's a multitude of things and all contribute a
>> >> millisecond or two so that it takes a while to render a frame in the
>> >> UI thread. to explain the issue i'm describing, imagine the mean depth
>> >> line jumping at 500ms intervals instead of smoothly following the
>> >> mouse.
>> >
>> >
>> > Actually, the line doesn't smootly follows the mouse for other reasons,
>> > if you see that the tooltipitem is not smootly updating, then there's a
>> > real
>> > issue.
>> >
>> > the line doesn't smootly follows the mouse because my implementation for
>> > it
>> > is wrong:
>> > if the current mouse position is not at a time that exists in the
>> > plot_info
>> > datastructure, it will not
>> > generate a line for that position.
>> >
>> > belive me, I'v tested by creating fake information and it worked.
>> >
>>
>> aha i see, but if i disable the hover code completely it's much
>> smoother in a way - no 500ms delays if moving quickly.
>>
>> >>
>> >>
>> >> 1) the main hog is ToolTipItem - 20%
>> >> perhaps elements can be re-used instead of re-creating them each time
>> >> the mouse moves.
>> >> also, we can possibly get rid of the animation and store some of the
>> >> VALUE / 2 operations in VALUE_D_2 consts. etc...
>> >> not sure how well this will work without testing it.
>> >
>> >
>> > The current API of the ToolTipItem supports this, but the main tooltip
>> > used
>> > is a *huge* text, sometimes with more than 16 lines of code
>> > we need to clean that - urgently.
>> >
>>
>> i was wondering if it would be possible to populate (allocate) the
>> tooltip with the maximum number of data elements ever to be used and
>> only show arrange elements when needed and resize the rectangle based
>> on that.
>
>
> The tooltip currently contains *one* item, each new line is just a massive
> string passed to it.

hmm, it doesn't seem that much text.

> so, I think most of the work is done by allocating that string, deleting it,
> generating the pixmap to be displayed ( rendering of fonts is always a
> massive cpu hog, the background of the notification is semitranslucent and
> it grows / shrinks.
>

my point was that perhaps we can try QGraphicsPixmapItem->setPixmap()
and QGraphicsSimpleTextItem->setText() instead of recreating the items
each time.
the text item seems the slowest.

> I wanna a bit of help iwth it.
> I wanna a bit of help with moving a node in the Add Dive, most of all.
> that's very sluggish and I was unable to solve. =/
>

there are other sluggish parts, indeed - even the main menu for some reason.

will see when i will get more free time.

lubomir
--