Performance regression when saving features

Advanced Use & Customization
1

Hi @nirvn,

I’m experiencing a significant performance regression when saving features in QField 4.1.1 compared to versions prior to 4.1 (last confirmed working version: 4.0.5). Saving a feature in the Observacion layer takes approximately 10 seconds in 4.1.6, while the same operation completes in about 1 second in 4.0.5.

Setup:

  • QGIS 3.40.11 (desktop)
  • QField >=4.1.x (field device, Android)
  • PostGIS/PostgreSQL backend, offline editing via QFieldCloud (layers packaged as GeoPackage on device)

Behaviour:

  • The delay occurs specifically when pressing the Save button, not while interacting with widgets
  • The regression is specific to one layer (Observacion). Other layers in the same project save instantly
  • The delay is consistent (~10 seconds) from the very first save after opening the project, regardless of how many features have been saved in that session

Layer characteristics:
The Observacion layer has 76 fields with the following widget distribution: 26 Range, 22 ValueRelation, 10 ValueMap, 10 CheckBox, 7 TextEdit, 1 DateTime.

Extensive troubleshooting already performed — none resolved the issue:

  1. Rewrote overlay_nearest() default value expressions to short-circuit eagerly in the majority of cases — no improvement
  2. Removed ALL default value expressions from the layer — no improvement
  3. Removed ALL constraint expressions from the layer — no improvement
  4. Removed the layer’s SQL filter (which included a subquery with now()) — no improvement
  5. Tested a minimal layer with 75 plain text fields, no expressions, no filters, published via QFieldCloud — save was instant
  6. Tested the same minimal layer with 20 fields configured as ValueRelation widgets pointing to a small lookup table — save was still instant

None of the individual characteristics of the Observacion layer reproduce the issue in isolation. The delay appears to be caused by a combination of factors specific to this layer’s full structure that only manifests in 4.1+.

I was unable to obtain a useful runtime profile from the Message Log, as the ‘Log runtime profile’ button only captures project load state, not the state immediately after a save operation.

I’m attaching the application log captured immediately after a save. Unfortunately I’m unable to share the project file due to confidentiality constraints, but I’m happy to answer any questions about its configuration.

Is there any additional diagnostic information I can provide to help identify the regression introduced between 4.0.5 and 4.1.0?

Thanks for your work on QField.

2

@Mathieu_Pellerin possibly interesting for you

3

@Angel_Martinez , would you be able to share your project for us to look at? You can do so privately by emailing me at mathieu@opengis.ch.

4

Ok @Mathieu_Pellerin
I’ll send you to the email.

Thank you very much for your support.

5

@Mathieu_Pellerin Solved!!!

Thank you very much!

1 Like
6

Good Morning @Angel_Martinez , if you do get a minute it would be interesting to see what the issue was and how it solved, Kind Regards

David.

1 Like
7

@DavyKay , the issue was a regression in QField, ironically tied to a really good optimization tied to tracking sessions.

The fix is here: Only update feature attributes/geometry that have actually changed by nirvn · Pull Request #7347 · opengisch/QField · GitHub , it’ll make its way into QField’s next patch release soon enough :slight_smile:

1 Like
8

@Mathieu_Pellerin , What does the improvement to the tracking session entail?

We’re having issues with recording long routes, with erroneous waypoints that are far off course, even when using the error distance safeguard setting. Would this be improved with the latest updates?

Thanks!!

9

@Angel_Martinez , assuming you are on a Samsung device, the erroneous waypoints are caused by a Samsung OS setting. See this thread: Strengthen tracker's maximum distance safeguard by ensuring non-measurable distances are dismissed by nirvn · Pull Request #7196 · opengisch/QField · GitHub