Bug report #10167: Deleting features in Attributes Table is very slow - QGIS Application - QGIS Issue Tracking

Bug report #10167

Deleting features in Attributes Table is very slow

Added by Johannes Kroeger over 10 years ago. Updated over 9 years ago.

Status:	Closed
Priority:	High
Assignee:	-
Category:	Attribute table
Affected QGIS version:	master	Regression?:	No
Operating System:		Easy fix?:	No
Pull Request or Patch supplied:	No	Resolution:
Crashes QGIS or corrupts data:	Yes	Copied to github as #:	18621

Description

When I delete many selected features in the Attribute Table view, it is very slow (minutes). When I just select them and then close the Attribute Table and delete them in the map view, it is quick (few seconds). I am using Shapefile layers.

To reproduce:
1. Have a layer with many features (say 250k), for example from the Random Points function.
2. Select a lot of them (say 50k)
3. Toggle editing
4a. Delete them via Edit -> Delete Selected. This should be fast.
4b. Open the Attribute Table, Delete them via Delete Selected Features. This should be slow.

Some similar but closed-as-fixed tickets I found: #5523, #7469

I am on Linux with:
QGIS version 2.3.0-Master
QGIS code revision eacb5bd
Compiled against Qt 4.8.6
Running against Qt 4.8.6
Compiled against GDAL/OGR 1.10.1
Running against GDAL/OGR 1.10.1
Compiled against GEOS 3.4.2-CAPI-1.8.2
Running against GEOS 3.4.2-CAPI-1.8.2 r3921
PostgreSQL Client Version 9.3.4
SpatiaLite Version 4.1.1
QWT Version 6.1.0
PROJ.4 Version 480
QScintilla2 Version 2.8.1

Associated revisions

Revision 8eca38ca
Added by Matthias Kuhn over 9 years ago

Attribute table performance when deleting features

This fixes performance issues with the attribute table visible when deleting a
large number of features.

The attribute table tries to behave smart in the following way:

It tries to remove only the deleted rows as long as they are in one or a few
single blocks
If there are more than 100 rows to delete and it starts to delete blocks
of a size smaller than 10 it assumes that the selection to delete is widely
distributed and that a reload of the whole model is less expensive than a
differential update.

Fix #10167

History

#1 Updated by Giovanni Manghi over 10 years ago

Crashes QGIS or corrupts data changed from No to Yes
Subject changed from Deleting features in Attribute Table very slow to Deleting features in Attributes Table is very slow
Category set to Vectors
Priority changed from Normal to High
Target version set to Version 2.4
Operating System deleted (~~Linux~~)
OS version deleted (~~eacb5bc~~)

I can confirm on different platforms and QGIs versions, but at least in my tests is does not depend on how many features are selected because it is slow (to delete from table) even if the number of selected features is little (within a large vector).

Deleting not in the table is extremely fast.

From table can be so slow that it can be compared to a complete freeze.

#2 Updated by Pedro Venâncio over 10 years ago

I also confirm this, both with QGIS 2.2 and 2.3 master, but I think that depends on the amount of features that are selected. Anyway, the difference compared with the delete from the canvas, it is quite evident, even with a few features selected.

This is most noticeable with layers with many features.

Tested with shapefiles and postgis layers, on Linux.

#3 Updated by Jürgen Fischer over 10 years ago

Deleting in the canvas and from the attribute table is the same. It's deleting features while having the attribute table (of that layer) open, that makes the difference.

#4 Updated by Matthias Kuhn over 10 years ago

The problem is that updating the table takes long. Most likely this is caused by the fact, that a single signal is sent for every removed feature and therefore the rows are removed one by one.

A couple of thoughts:

It would be possible to catch the editCommandStarted to start buffering operations and then execute these at once when editCommandEnded is emitted.
It would be possible to emit a single signal with a list of all features which are removed from the vector layer. The result is the same, but the list of features to remove is known already (=selection) and if any other part of the code struggles with the same as the attribute table, it will not have to duplicate the buffering code. <== my favorite
Reload the whole model (table) on editCommandEnded. The signal does not tell what changed, so reloading would also occur on attributeChange and loading can take a long time. ==> Bad idea.