https://issues.qgis.org/https://issues.qgis.org/favicon.ico2014-02-08T13:30:06ZQGIS Issue TrackingQGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=483442014-02-08T13:30:06ZJürgen Fischerjef@norbit.de
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Fixed in changeset <a class="changeset" href="https://issues.qgis.org/projects/qgis/repository/revisions/52616b6549bf43eee3cccc79f73aa890da5f3fab" title="vector layer: save old attribute values where available to speedup undo (and rollback) (fixes #95...">52616b6549bf43eee3cccc79f73aa890da5f3fab</a>.</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=483782014-02-09T05:43:24ZSalvatore Larosalrssvtml@gmail.com
<ul></ul><p>For me it still not fixed. I am getting always a QGIS freezing on rollback action.</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=483792014-02-09T06:03:52ZJürgen Fischerjef@norbit.de
<ul></ul><p>Salvatore Larosa wrote:</p>
<blockquote>
<p>For me it still not fixed. I am getting always a QGIS freezing on rollback action.</p>
</blockquote>
<p>It's faster. But the changes need to be rolled back one by one and therefore the time it takes to rollback is somewhat the same as to do the changes in the first place.</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=483842014-02-09T08:19:05ZMatthias Kuhn
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>Reopened</i></li></ul><p>It's not quite the same, as when doing changes the first time via the field calculator, one iterator is opened and looped while in a rollback, there is one iterator per feature.</p>
<p>Quote from <a class="issue tracker-1 status-5 priority-5 priority- closed" href="https://issues.qgis.org/issues/9519" title="Rollback operations slow if lots of features changed (Closed)">#9519</a></p>
<blockquote>
<p>As far as I can tell, there are feature requests made for every single feature which was updated before (so all in the case mentioned above).<br />I could imagine a possible approach would be to batch undo the affected rows and perform a single request with setFilterFids() to still only request the required rows, but with less roundtrips.</p>
</blockquote> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=483852014-02-09T08:25:27ZJürgen Fischerjef@norbit.de
<ul></ul><p>Matthias Kuhn wrote:</p>
<blockquote>
<p>It's not quite the same, as when doing changes the first time via the field calculator, one iterator is opened and looped while in a rollback, there is one iterator per feature.</p>
</blockquote>
<p>Not anymore. That was the case when the previous values were not stored in the first undo command - therefore the original value had to be retrieved from the provider using a iterator. Now that only happens if an attribute change happens when the previous value isn't already available (which is not the case in the field calculator).</p>
<p>Still all subscribers to the attributeValueChanged signal must be notified that the value was changed back (BTW the dualview form view doesn't update in that case).</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=483972014-02-10T01:01:37ZMatthias Kuhn
<ul></ul><p>Jürgen Fischer wrote:</p>
<blockquote>
<p>Not anymore. That was the case when the previous values were not stored in the first undo command - therefore the original value had to be retrieved from the provider using a iterator. Now that only happens if an attribute change happens when the previous value isn't already available (which is not the case in the field calculator).</p>
</blockquote>
<p>So the problem is the field calculator not saving the previous values?</p>
<blockquote>
<p>Still all subscribers to the attributeValueChanged signal must be notified that the value was changed back (BTW the dualview form view doesn't update in that case).</p>
</blockquote>
<p>I can take care of that. I think introducing an afterRollback signal should do the trick.</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=483982014-02-10T01:05:22ZMatthias Kuhn
<ul></ul><p>Ah, the form view and not the table view.</p>
<p>/me should read more carefully.</p>
<p>I will take care of this for 2.4 with the new editor components.</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=484012014-02-10T01:18:15ZJürgen Fischerjef@norbit.de
<ul></ul><p>Matthias Kuhn wrote:</p>
<blockquote>
<p>Jürgen Fischer wrote:</p>
<blockquote>
<p>Not anymore. That was the case when the previous values were not stored in the first undo command - therefore the original value had to be retrieved from the provider using a iterator. Now that only happens if an attribute change happens when the previous value isn't already available (which is not the case in the field calculator).</p>
</blockquote></blockquote>
<blockquote>
<p>So the problem is the field calculator not saving the previous values?</p>
</blockquote>
<p>IMHO there is no problem anymore. The rollback is faster now, as it doesn't need to reload the values from the provider, but it still needs time because it needs to signal each undo - and that's by design.</p>
<p>We only have the attributeValueChange signal and subscribers can currently assume that they will be notified for each change. We could introduce a bulkAttributeValueChange signal (and undo command), that tells subscribers that all the values of an attribute changed (maybe include fid ranges or fid sets) and define that attributeValueChange doesn't cover bulk changes. But that would be a feature.</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=484052014-02-10T01:37:51ZMatthias Kuhn
<ul></ul><p>I am not at home to test now but when I tested yesterday it seemed to me that the field calculator is still faster than the rollback - and they should emit the same amount of signals. Maybe the decrease in performance is related to debug output the rollback produces.</p>
<p>bulkAttributeValueChange signal would be fine, but on the other hand I experienced that caching values retrieved from attributeChanged signals and postponing heavy operations to editCommandEnded() works very well. So the signals themselves seem to be a minor problem as long as their implementations are not performance-killers. The only remaining problem with this approach I can think of is that if several consumers cache the values it's a waste of memory.</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=484072014-02-10T02:05:29ZJürgen Fischerjef@norbit.de
<ul></ul><p>Matthias Kuhn wrote:</p>
<blockquote>
<p>I am not at home to test now but when I tested yesterday it seemed to me that the field calculator is still faster than the rollback - and they should emit the same amount of signals. Maybe the decrease in performance is related to debug output the rollback produces.</p>
</blockquote>
<p>Before or after <a class="changeset" href="https://issues.qgis.org/projects/qgis/repository/revisions/52616b6549bf43eee3cccc79f73aa890da5f3fab" title="vector layer: save old attribute values where available to speedup undo (and rollback) (fixes #95...">52616b6</a>? I didn't do benchmarking either, but the test expression to update and undo I used was trivial.</p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=484872014-02-11T21:15:08ZMatthias Kuhn
<ul></ul><p>Tested again with current master.</p>
<p>I noticed, that when <em>updating</em> a column, the rollback is fast. But when I <em>add</em> a newly calculated column that's what takes so long to rollback.</p>
<p>In the latter case the debug output I mentioned is:<br /><pre>
src/providers/postgres/qgspostgresconn.cpp: 825: (openCursor) Starting read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 839: (closeCursor) Committing read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 825: (openCursor) Starting read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 839: (closeCursor) Committing read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 825: (openCursor) Starting read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 839: (closeCursor) Committing read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 825: (openCursor) Starting read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 839: (closeCursor) Committing read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 825: (openCursor) Starting read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 839: (closeCursor) Committing read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 825: (openCursor) Starting read-only transaction
</pre></p> QGIS Application - Bug report #9509: Discarding edits freezes qgis for a long timehttps://issues.qgis.org/issues/9509?journal_id=485012014-02-12T04:10:51ZJürgen Fischerjef@norbit.de
<ul><li><strong>Status</strong> changed from <i>Reopened</i> to <i>Closed</i></li></ul><p>Fixed in changeset <a class="changeset" href="https://issues.qgis.org/projects/qgis/repository/revisions/5bee17218db3576a6a172eec5ef6d555fc023b4d" title="* speed up undo of attribute added with field calculator (fixes #9509) * also improves performanc...">5bee17218db3576a6a172eec5ef6d555fc023b4d</a>.</p>