Slow switching between dives?

[Tomaz Canabrava]

On Fri, Sep 29, 2017 at 2:56 AM, Lubomir I. Ivanov <neolit123 at gmail.com>
wrote:

> 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?
>

We actually never updated the dive profile async. The code that does the
update is Widget-related and that can only be updated on the main thread.
We can try to speed up a few things here and there but I prefer to analize
the code before saying anything.


>
> > 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
> --
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170929/05eb3b75/attachment.html>