[Qgis-psc] Performance regressions (was QGIS 2.18 bug fixing effort)

[Nathan Woodrow]

Hmm I wonder what the regression in the SQL server driver is. I added a is
valid check although that should have low overhead.

On Thu, 25 May 2017, 9:49 AM Mathieu Pellerin <nirvn.asia at gmail.com> wrote:

> On the 3.0 vs 2.x load time issue, there's a one time operation we do in
> 3.0 which we didn't do earlier, namely the creation of the saved style
> database (ie import of styles stored in symbology-ng.xml).
>
> As I mentioned above, it's a one time operation, so the load time cost is
> only occuring upon launching QGIS with an empty user profile directory.
> Subsequent load times aren't impacted.
>
> On my machine, the import takes 650ms (or actually less, I can't remember).
>
> On May 25, 2017 5:50 AM, "Nyall Dawson" <nyall.dawson at gmail.com> wrote:
>
> On 25 May 2017 at 02:20, Giovanni Manghi <giovanni.manghi at gmail.com>
> wrote:
> > Hi Nyall
> >
> >
> >
> >> - it's not possible to directly compare the repo provided versions vs
> >> self-compiled builds. They'll be built using different compilers with
> >> different optimisation levels. Are you able to re-run the tests which
> >> used the repo builds with self-compiled builds instead?
> >
> >
> > I compiled tag final-2_18_8 and I confirm that with "time" results
> > (start qgis + loading a large dataset) are basically the same as the
> > ones obtained by compiling the 2.18 branch.
>
> Great - thanks for the confirmation. I've just finished another round
> of benchtesting and here's my conclusions:
>
> 1. Attribute table performance is fixed and back to 2.14.0 speed.
>
> 2. There's been no regressions in rendering speed or layer loading
> speed from 2.14.0 -> 2.18.8. Tested with a variety of layer geometry
> types & sizes on Ubuntu 16.04, using release builds. Only shapefiles
> and the OGR provider were tested.
>
> 3. There's strong evidence that we have a severe performance
> regression just in the mssql provider
> (https://issues.qgis.org/issues/15752). I believe that bug should be
> reopened but renamed to reflect that it affects mssql only. Note that
> I haven't confirmed this regression or run any benchtests on it yet.
>
> 4. Giovanni's tests have revealed a regression in the load times for
> QGIS (as opposed to rendering/layer loading times). This is somewhat
> expected. The majority of QGIS' load time occurs with loading the
> processing plugin, and specifically with adding all the providers and
> algorithms. So given the vastly increased number of algorithms
> available in 2.18 vs 2.14, it's a natural (but unfortunate) side
> effect. I think we'll have to just live with this in 2.x. For 3.x we
> could probably move the algorithm/provider initialization to a
> background tasks which is kicked off only after the QGIS interface has
> loaded.
>
> Giovanni - do you agree with these conclusions?
>
> Nyall
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20170525/a5393ad8/attachment.html>