Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subsequent selections kill QGIS ui performance #41366

Closed
rduivenvoorde opened this issue Feb 4, 2021 · 7 comments · Fixed by #41382
Closed

Subsequent selections kill QGIS ui performance #41366

rduivenvoorde opened this issue Feb 4, 2021 · 7 comments · Fixed by #41382
Assignees
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Map Tools Related to non-digitizing map tools

Comments

@rduivenvoorde
Copy link
Contributor

rduivenvoorde commented Feb 4, 2021

When creating a selection in a rather large dataset, the first time is pretty fast.

BUT if you then change the way of selecting (for example change from select by Value to select by Expression) THEN Qgis stalls.

How to Reproduce

  • download the osm-line gpkg from https://www.dropbox.com/sh/kfj9bptiiwjccqe/AADGppvIBEoztMeh5RP_FUlxa?dl=0
  • now create a selection by Expression with "railway"='rail' Result: fast selection of 28000 features
  • now switch to 'select by Value' (while the old selection is still visible)
  • this result in... QGIS stalling/freezing and the normal select by Value dialog does nog show up.
  • it will take A LONG time for the dialog to show
  • NOTE: when you stay with the SAME way of selecting (say selecting by Expression twice), there is NOT slow dialog popup

Is QGIS at that moment 'unselecting' the earlier selection? Or... what is it that QGIS is busy with?

Running 3.16 or master on Linux

@rduivenvoorde rduivenvoorde added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Feb 4, 2021
@gioman gioman added Crash/Data Corruption Map Tools Related to non-digitizing map tools labels Feb 4, 2021
@gioman
Copy link
Contributor

gioman commented Feb 4, 2021

O yeah, confirmed here too on master.

@rduivenvoorde
Copy link
Contributor Author

rduivenvoorde commented Feb 5, 2021

I'm going to try Hotspot as Nyall was showing in his bugfixing video:
https://youtu.be/du5DSWik3V4?t=4562

Mmm, using Hotspot appimages (both latest and nightly) crash as soon as I try to attach to running QGIS.
Tried compiling myself but would need to install kdab dock widgets from external repo, which I prefer not to do...
@nyalldawson how did you manage this?

@elpaso
Copy link
Contributor

elpaso commented Feb 5, 2021

When creating a selection in a rather large dataset, the first time is pretty fast.

BUT if you then change the way of selecting (for example change from select by Value to select by Expression) THEN Qgis stalls.

How to Reproduce

* download the osm-line gpkg from https://www.dropbox.com/sh/kfj9bptiiwjccqe/AADGppvIBEoztMeh5RP_FUlxa?dl=0

* now create a selection by Expression with "railway"='rail' Result: fast selection of 28000 features

* now switch to 'select by Value' (while the old selection is still visible)

* this result in... QGIS stalling/freezing and the normal select by Value dialog does nog show up.

* it will take A LONG time for the dialog to show

* NOTE: when you stay with the SAME way of selecting (say selecting by Expression twice), there is NOT slow dialog popup

Is QGIS at that moment 'unselecting' the earlier selection? Or... what is it that QGIS is busy with?

Fetching features by id (the ids of the previously selected features).

@rduivenvoorde
Copy link
Contributor Author

rduivenvoorde commented Feb 5, 2021

@elpaso is that needed to be able to (optionally) merge the new selection to the old one?

So you think adding an index on the id (if available) would help? Will try it now...
OR is it just busy with fetching these 27000 (rather large, a lot of attributes) features, and an index would not be helpfull? If so would cleaning up this osm data (eg removing a lot of attributes) help?

AND another question to me: why does this behaviour only show when you change the way to do the selection, and NOT when you keep the same?

@elpaso
Copy link
Contributor

elpaso commented Feb 5, 2021

@elpaso is that needed to be able to (optionally) merge the new selection to the old one?

So you think adding an index on the id (if available) would help? Will try it now...

No, it won't help for the reason you mention below and I'm pretty sure GPKG already has an index on the fid.

OR is it just busy with fetching these 27000 (rather large, a lot of attributes) features, and an index would not be helpfull? If so would cleaning up this osm data (eg removing a lot of attributes) help?

AND another question to me: why does this behaviour only show when you change the way to do the selection, and NOT when you keep the same?

Sorry, I'm busy on other issues and I only had time for a quick debug run yesterday evening, the only evidence I have so far is that it gets stuck on retrieving every single feature individually by id, because of the existing selection.

I'll see if I can have a closer look later.

@nyalldawson
Copy link
Collaborator

I'll take a look if you want @elpaso?

@elpaso
Copy link
Contributor

elpaso commented Feb 5, 2021

I'll take a look if you want @elpaso?

Yes, please 😃

@nyalldawson nyalldawson self-assigned this Feb 5, 2021
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Feb 8, 2021
field) when the attribute form is opened.

This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).

Refine logic to avoid the scan wherever we can.

Fixes qgis#41366
Fixes qgis#36863
nyalldawson added a commit that referenced this issue Feb 9, 2021
field) when the attribute form is opened.

This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).

Refine logic to avoid the scan wherever we can.

Fixes #41366
Fixes #36863
github-actions bot pushed a commit that referenced this issue Feb 9, 2021
field) when the attribute form is opened.

This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).

Refine logic to avoid the scan wherever we can.

Fixes #41366
Fixes #36863
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Feb 16, 2021
field) when the attribute form is opened.

This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).

Refine logic to avoid the scan wherever we can.

Fixes qgis#41366
Fixes qgis#36863

(cherry picked from commit c661359)
nyalldawson added a commit to nyalldawson/QGIS that referenced this issue Feb 19, 2021
field) when the attribute form is opened.

This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).

Refine logic to avoid the scan wherever we can.

Fixes qgis#41366
Fixes qgis#36863

(cherry picked from commit c661359)
nyalldawson added a commit that referenced this issue Feb 19, 2021
field) when the attribute form is opened.

This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).

Refine logic to avoid the scan wherever we can.

Fixes #41366
Fixes #36863

(cherry picked from commit c661359)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Map Tools Related to non-digitizing map tools
Projects
None yet
4 participants