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

[Mathieu Pellerin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20170525/ff40c205/attachment.html>