[Qgis-developer] Benchmarking QgsExpression against V8

[Marco Hugentobler]

Hi Martin

 >- it may be interesting to measure the proportion of time necessary
 >for field calculation / searching. I believe the the evaluation takes
 >just a small amount of time compared to time required for fetching of
 >features, therefore a fast engine might not necessarily speed things
 >up significantly

That would be very interesting (probably it can be tested much better 
now thanks to qgis_bench).

My only experience here was the WMS benchmark 2011 with many layers and 
a lot of expressions (osm data, a lot of classification rules, many 
layers). For requests with a lot of features in view, expression 
evaluation showed up considerably in the profiler, both in QGIS server 
and UMN mapserver. Yes, feature fetching wasn't considered (still 
cachegrind) and I don't have the cachegrind dumps at hand. However, it 
still shows that there are use-cases where evaluation is not neglectable.


Regards,
Marco

On 10.01.2012 14:03, Martin Dobias wrote:
> On Tue, Jan 10, 2012 at 1:00 AM, Pirmin Kalberer<pi_ml at sourcepole.com>  wrote:
>> Pros:
>> -Better performance
>> -Full Javascript language set included
>> -Possibility for writing custum functions
>>
>> Cons:
>> -New language for expressions
>> -More fat (3.7MB for libv8.so)
> Thanks for the benchmark.
>
> I have several things to note:
> - it may be interesting to measure the proportion of time necessary
> for field calculation / searching. I believe the the evaluation takes
> just a small amount of time compared to time required for fetching of
> features, therefore a fast engine might not necessarily speed things
> up significantly
> - V8 may be aware of the fact that the benchmarked expressions are
> constant - and evaluate them during compilation, resulting in much
> shorter execution time. It would be good to include a benchmark that
> uses variables (column references).
> - the engine implements three value logic (true/false/unknown) like in
> SQL, while JavaScript (AFAIK) uses usual two value (true/false) logic.
> How would you add support for NULL values in operators?
> - Python is another language which could be used for the expressions -
> with similar advantages as JavaScript
>
> At some point we may support several languages for expressions
> (ideally with just one evaluation engine). Regarding JavaScript, as
> Juergen noted, there is already JavaScript engine in Qt, so adding V8
> dependency looks like a high cost for the exchange of faster
> expression evaluation. My impression is that such a state of the art
> engine makes sense for web apps with thousands of lines in JavaScript,
> but not that much for simple expressions.
>
> Regards
> Martin
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux&  Open Source Solutions
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee