the profile is becoming a bit of a cpu hog

[Lubomir I. Ivanov]

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.

addToolTip() / clear() seem to use the most cpu.

>>
>> 2) those extra 10% are caused by the new
>> InstantMeanDepthLine::mouseMoved()
>> as it calculates based on the running average each time instead of
>> using a lookup table.
>
>
> Hm... can you ( or anyone else ) help me to create a lookup table?
>

will post again in a moment.

lubomir
--