QgisCadastrePlugin
QgisCadastrePlugin copied to clipboard
3liz
Amélioration des performances pour le remplissage de la table geo_batiment_parcelle
Nous travaillons sur de bonnes machines (i7, 16 Go de RAM) sous Windows 10 et nous avons noté une régression des temps d'import des données cadastrales depuis l'année dernière. En gros, depuis la version 1.8.0 avec laquelle nous avons traité nos données depuis fin août 2019.
Ci-dessous un tableau qui résume nos tests d'import uniquement des données EDIGEO, sur 10 communes (201 sections, 48500 parcelles, 43200 bâtiments). Nos PostGIS sont les mêmes que l'année dernière (PostgreSQL 11 + PostGIS 2.5).
| version plugin | version QGIS | PostGIS |
|---|---|---|
| 1.8.0 | 3.4 | 275 s |
| 1.8.0 | 3.10 | 267 s |
| 1.8.1 | 3.4 | 387 s |
| 1.8.1 | 3.10 | 380 s |
| master (fix 240) | 3.4 | - |
| master (fix 240) | 3.10 | 372 s |
| master + fix_196 + fix_221 + majic 2020 | 3.4 | 423 s |
| master + fix_196 + fix_221 + majic 2020 | 3.10 | 380 s |
On a recommencé 2 x les imports et on obtient à peu près les mêmes valeurs sur 2 ordis différents mais à config équivalente.
Ce qui nous interpelle c'est qu'on prend entre + 40 % et + 50 % de temps de traitement supplémentaire entre la 1.8.1 et la version master actuelle. Nos récents ajouts (PR en attente) ne change pas la donne. Sauf que quand on regarde les commits faits entre la 1.8.0 et l'état actuel de master.
Une idée de la cause de ce ralentissement ?
En faisant un git revert e4e98f048b6f10aaad3e4a3689d819c30aec31dc donc en annulant https://github.com/3liz/QgisCadastrePlugin/commit/e4e98f048b6f10aaad3e4a3689d819c30aec31dc on retombe autour des 270 s.
Que fait-on @mdouchin ? Quel était la motivation de ce changement ?
Le coût de la nouvelle requête est beaucoup plus faible que celui de l'ancienne. Le problème peut provenir de vos index spatiaux pour ST_Centroid(geom) de la couche geo_batiment et geom de la couche geo_parcelle.
Je pense que cela dépend fortement du contexte:
- utilisation de PostgreSQL ou de Sqlite (le dernier pouvant avoir des soucis de performances sur les tests spatiaux ?)
- volumétrie des données
- qualité des données EDIGEO (notamment sur les données de relations stockées dans edigeo_rel
Je pense que cela simplifiait aussi les choses : pour savoir quels bâtiment est sur quelle parcelle, il paraissait plus simple de faire une requête spatial plutôt que de faire confiance aux données MAJIC.
Il faudrait faire une matrice de test plus complexe, pour croiser les 3 critères
- volumétrie des données: commune, agglo, département
- bdd: spatialite ou postgres
- requête : par ST_Intersects ou par jointure attributaire (correspond à la version du plugin)
La version de QGIS importe peu, car ce sont des requêtes SQL qui sont effectuées, donc normalement il ne devrait pas y avoir d'impact.
Le fait d'importer MAJIC ou pas n'importe normalement pas non plus, car dans les 2 types de requête, aucune table MAJIC n'est mobilisée.
Peut-être proposer une option pour basculer de l'un à l'autre, ou en fonction des tests, choisir telle ou telle requête en fonction du type de bdd (postgres via sqlite), du nombre de communes ?
Revert effectué via ac6e858e35e3ccabd356153464e258b15e5359eb
Je vais relancer les tests