[Qgis-developer] Performance of QGIS expressions "attribute" and "get_feature"

[Stefan Ziegler]

I looked at the debug output. This time I did not add a virtual field but
only using the expression in the rule based renderer:

src/core/qgsvectorlayerrenderer.cpp: 94: (QgsVectorLayerRenderer) [3ms]
rendering v2:
  Rule-based renderer:
RULE  - scale [0,0] - filter  - symbol []
  RULE  - scale [0,0] - filter
attribute(get_feature('einzelobjekte_einzelobjekt','t_id',flaechenelement_von),'art')
= 'unterirdisches_Gebaeude' - symbol FILL SYMBOL (1 layers) color
121,174,87,255

src/core/qgsmaprenderercustompainterjob.cpp: 100: (start) [0ms] Rendering
prepared in (seconds): 0.004
src/core/qgsmaprenderercustompainterjob.cpp: 232: (doRender) [0ms]
[thread:0x23feda0] Starting to render layer stack.
src/core/symbology-ng/qgsrulebasedrendererv2.cpp: 839: (startRender) [0ms]
[thread:0x23feda0] zLevel 0 -> 0
src/providers/postgres/qgspostgresconn.cpp: 992: (openCursor) [2ms]
[thread:0x23feda0] Starting read-only transaction: 90310
src/providers/postgres/qgspostgresconn.cpp: 992: (openCursor) [2ms]
[thread:0x23feda0] Starting read-only transaction: 90310
src/providers/postgres/qgspostgresconn.cpp: 1010: (closeCursor) [9ms]
[thread:0x23feda0] Committing read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 992: (openCursor) [1ms]
[thread:0x23feda0] Starting read-only transaction: 90310
src/providers/postgres/qgspostgresconn.cpp: 1010: (closeCursor) [9ms]
[thread:0x23feda0] Committing read-only transaction
src/providers/postgres/qgspostgresconn.cpp: 992: (openCursor) [1ms]
[thread:0x23feda0] Starting read-only transaction: 90310
src/providers/postgres/qgspostgresconn.cpp: 1010: (closeCursor) [10ms]
[thread:0x23feda0] Committing read-only transaction
src/providers/postgres/qgspostgresfeatureiterator.cpp: 242: (fetchFeature)
[1ms] [thread:0x23feda0] Finished after 2 features
src/providers/postgres/qgspostgresconn.cpp: 1010: (closeCursor) [0ms]
[thread:0x23feda0] Committing read-only transaction
src/core/qgsmaprenderercustompainterjob.cpp: 261: (doRender) [3ms]
[thread:0x23feda0] Done rendering map layers
src/core/qgsmaprenderercustompainterjob.cpp: 272: (drawLabeling) [0ms]
[thread:0x23feda0] Draw labeling start
src/core/qgsvectorlayer.cpp: 320: (drawLabels) [0ms] [thread:0x23feda0]
Starting draw of labels: einzelobjekte_flaechenelement20151230200140594
src/core/qgsmaprenderercustompainterjob.cpp: 299: (drawLabeling) [0ms]
[thread:0x23feda0] Draw labeling took (seconds): 0
src/core/qgsmaprenderercustompainterjob.cpp: 266: (doRender) [0ms]
[thread:0x23feda0] Rendering completed in (seconds): 0.038
src/core/qgsmaprenderercustompainterjob.cpp: 201: (futureFinished) [1ms]
QPAINTER futureFinished
src/core/qgsmaprendererjob.cpp: 327: (cleanupJobs) [0ms] caching image for
einzelobjekte_flaechenelement20151230200140594
src/core/qgsmaprenderersequentialjob.cpp: 121: (internalFinished) [0ms]
SEQUENTIAL finished
src/gui/qgsmapcanvas.cpp: 698: (rendererJobFinished) [0ms] CANVAS finish! 1
src/core/qgsmaprenderercustompainterjob.cpp: 41:
(~QgsMapRendererCustomPainterJob) [3ms] QPAINTER destruct
src/core/qgsmaprenderersequentialjob.cpp: 38:
(~QgsMapRendererSequentialJob) [4ms] SEQUENTIAL destruct

For few features visible in the mapcanvas it is fast. But really slows down
when zooming out. I checked the "execute expression on server side option".
With this enabled I would assume that qgspostgresfeatureiterator.cpp would
fetch only 1 feature if there is only 1 feature visible in the mapcanvas
(according with the filter/expression)? But it alwas fetches all possible
features in the map canvas (two in my case).

regards
Stefan


On Wed, Dec 30, 2015 at 9:34 PM, Stefan Ziegler <stefan.ziegler.de at gmail.com
> wrote:

> Two postgres layers with an index on the fields.
>
> Do I see some debug messages (when compiled with DEBUG)?
>
> On Wed, Dec 30, 2015 at 9:27 PM, Nyall Dawson <nyall.dawson at gmail.com>
> wrote:
>
>> On 31 December 2015 at 06:18, Stefan Ziegler
>> <stefan.ziegler.de at gmail.com> wrote:
>> > Hi Nyall
>> >
>> > I compared 2.12 with current master. But I don't see an improvement.
>> Opening
>> > the attribute table takes around 10 seconds for layers with approx. 2000
>> > features with one virtual field (with the attribute(get_feature())
>> > expression). Rendering is also really slow when using rule based
>> renderer on
>> > the virtual field.
>>
>> What's the data source for each layer? If it's in a database (eg
>> postgres), is there a suitable index on the joined field?
>>
>> Nyall
>>
>>
>>
>> >
>> > regards
>> > Stefan
>> >
>> > On Wed, Dec 30, 2015 at 7:22 PM, Nyall Dawson <nyall.dawson at gmail.com>
>> > wrote:
>> >>
>> >>
>> >> On 31 Dec 2015 2:01 AM, "Stefan Ziegler" <stefan.ziegler.de at gmail.com>
>> >> wrote:
>> >> >
>> >> > Hi
>> >> >
>> >> > I add a virtual field to a layer with e.g. following expression
>> >> >
>> >> > attribute(get_feature('pnf_pnf','t_id',afrom),'year')
>> >> >
>> >> > This works really great. Then I'm using this new virtual field for
>> >> > filtering the features in the rule based renderer. How does affect
>> this the
>> >> > rendering performance? It seems that it really slows down rendering
>> even
>> >> > with layers with only approx 600 features each.
>> >> >
>> >> > If so, can the speed improved with e.g. some to develop caching
>> >> > mechanism?
>> >>
>> >> Try with the current master version - this should be MUCH faster now.
>> I'd
>> >> love to hear any feedback of how you find the changes improve (or don't
>> >> improve!) your situation.
>> >>
>> >> Nyall
>> >>
>> >> >
>> >> > regards
>> >> > Stefan
>> >> >
>> >> > _______________________________________________
>> >> > Qgis-developer mailing list
>> >> > Qgis-developer at lists.osgeo.org
>> >> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151231/ef317ced/attachment.html>