Slow switching between dives?

[Lubomir I. Ivanov]

On 29 September 2017 at 03:05, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> Ho humm. I haven't actually bisected this or anything, but I'm hoping
> somebody else noticed and might have picked up on when this started..
>
> I've got a fast CPU, but switching dives isn't "instant". You can
> particularly tell when just scrolling down the dive list using the
> cursor keys. It's not *slow*, but it sure isn't fast.
>
> We used to have this situation where the deco processing took up a lot
> of time, but that doesn't seem to be it. Yes, "add_segment()" is
> fairly high in the profiles at 11% of CPU time, and "factor()" is
> another 4% or so, but that's pretty much it. Most of the time seems to
> be GUI costs.
>
> The top entry in a profile of me scrolling down the list is
>
>   12.55%  qt_qimageScaleAARGBA_down_xy_sse4<false>
>
> but there's some truetype code at 3% and a lot of libQt5Gui stuff in
> the ~1% range.
>
> I *thought* we used to update the dive profile asynchronously so that
> you could step down the dive log without waiting for the profile to
> render all the time. Has that code bit-rotted perhaps?
>
> Or is it just me?
>

i'm on a relatively slow machine and it has been always kind of slow
to switch between dives, so i can't really tell the difference.
just did a quick profiling myself to see if it's the map widget is
responsible and i do not observe heavy loads in QtLocation,
QtPositioning, QtQml.

might still be it, but my guess is that it's unrelated to the new map.

lubomir
--