As far as I understand: for every feature of the layer intersecting the map
canvas there is a openCursor and closeCursor command. Without the
expression you only have one openCursor and closeCursor command for the
layer. Don't know if this is necessary but it seems to slow it down.
regards
Stefan
On Thu, Dec 31, 2015 at 9:38 AM, Stefan Ziegler <stefan.ziegler...@gmail.com
> wrote:
> 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...@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.daw...@gmail.com>
>> wrote:
>>
>>> On 31 December 2015 at 06:18, Stefan Ziegler
>>> <stefan.ziegler...@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.daw...@gmail.com>
>>> > wrote:
>>> >>
>>> >>
>>> >> On 31 Dec 2015 2:01 AM, "Stefan Ziegler" <stefan.ziegler...@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@lists.osgeo.org
>>> >> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> >> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> >
>>> >
>>>
>>
>>
>
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
