On 29 September 2017 at 03:05, Linus Torvalds <[email protected]> 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 -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
