* mesh expression $vertex_as_point $vertex_Z_value
* functions help
* SIP, doc and indentation
* fix SIP
* fix help file
* change function name and add Meshes group description
* fix typo
* fix strings and docs
* typo
during preparation wherever possible
In many situations we are able to optimize a case when expression
and replace it with a simpler expression node during the preparation
stage. Specifically, if the WHEN conditions are known to be
static values (such as those coming from certain expression context
variables) then we can often replace the whole condition node
with the THEN node of the first static true condition.
E.g.
CASE
WHEN @variable=1 THEN "first_field"
WHEN @variable=2 THEN "second_field"
ELSE "third_field"
END
If @variable is static and '1', then the whole expression node will ALWAYS
be identical to "first_field". Similiarly if @variable='2', then the
whole expression will ALWAYS be "second_field".
If we're able to apply this optimization, then we use the simplified
effective node which represents the whole node during evaluation
time and save a bunch of unnecessary work.
TODO: If we use the effective node during expression compilation
for providers we would be able to handoff more expressions involving
QGIS-side variables and other components to the backend, resulting
in increased use of backend provider indices, etc....
stage, be more intelligent about compiling AND or OR nodes
We can take advantage of the fact that and AND node will ALWAYS
be false if either input node is static and evaluates to FALSE,
and that OR nodes will always be true if either input is static
and evaluates to TRUE.
In some cases this allows us the shortcut and cut out non-static
nodes during preparation, resulting in faster evaluation and
more easily compiled expressions...
the referenced fields of an expression
Avoids some cases where use of various expression functions which
normally trigger all attributes to be requested, yet can be pre-computed
during prepare stages, cause non-provider fields to be listed in
the referenced columns and accordingly prevent expression compilation.
Notably this can occur when using an expression like:
aggregate( .... , filter:=
"some_child_field"=attribute(@atlas_feature, 'some_atlas_field_name') )
where the whole attribute(@atlas_feature....) part is a constant
static value and can be compiled down to a trivial, index-friendly
"some_child_field"=### filter for the aggregate provider request.
Ultimately giving a big performance boost to the atlas!
check if a node has already been determined to evaluate to a static,
precalculated value, and if so, use this value for the node instead
of attempting to compile the actual contents of the node itself
If we are certain that a node is static and will never change,
the this potentially allows us to short-cut a large part of the
filter expressions content. We already use this short-cut when
evaluating expressions on the QGIS side since years, and its
proven to be stable and reliable. By respecting this during
expression compilation we can offer a huge speed up to certain
filter expressions, especially those which utilise QGIS variables
which are known to be static (such as atlas variables, map scales,
etc). Previously ANY use of a qgis variable would always cause
expression compilation to fail and require a full set of feature
fetching from the provider.
(Resulted in orders of magnitude faster atlas export for a complex
atlas.)
"field=value" type expression, and for condensing a list of similar
expressions to an equivalent "field IN (value, value2,...)" expression
wherever possible
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
All your uses of toUtf8().data() actually just need a const char*
So use constData() that is semantically more correct, and documented
to be faster.
From http://doc.qt.io/qt-5/qbytearray.html#data
"For read-only access, constData() is faster because it never
causes a deep copy to occur."
Checks whether a function declaration has parameters that are
top level const.
const values in declarations do not affect the signature of a
function, so they should not be put there.
- nodes() return the list of all nodes
- findNodes<T> returns a list of the nodes matching the class
Also drops the regexp for finding form attrs in the value-relation
expressions.
Other minor fixes as suggested in the PR review.
