Bug report #2297
XML parsing slows down WFS and GML loading
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  nobody - | ||
| Category: | Data Provider | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | All | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | invalid | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 12357 |
Description
WFS loading is very slow: I always thought that was due to bandwidth, but now it seems more likely that XML parsing is the culprit (thanks Furieri for noticing!). The same can be see in GML loading from local file. The effect seems particularly heavy on Windows.
History
#1
Updated by Marco Hugentobler over 14 years ago
Is there a test server instance / test file?
The WFS provider uses a different approach than the GML reader of OGR. So probably they are slow for different reasons.
And yes, reading XML is more demanding performance wise than reading the same information in a binary format.
#2
Updated by Paolo Cavallini over 14 years ago
This should be a good and fast server, rather slow to download:
#3
Updated by Paolo Cavallini over 14 years ago
While loading, the bottleneck seems CPU, that goes up (98-99%)
#4
Updated by Marco Hugentobler over 14 years ago
I tested it with the layer ras:IDT_MN11V_DATI_AGGR_PROV. (22MB) with wget and the WFS plugin. I didn't measure the time exactly, but it seemed comparable to me, appr. 60 - 70 seconds.
The reason the CPU works while loading is that the WFS provider does asynchronous request and starts parsing before the whole document has arrived.
#5
Updated by Paolo Cavallini over 14 years ago
- Resolution set to invalid
- Status changed from Open to Closed
So better close it - still unsure about GML though, but this will require more testing, especially on Windows.