Skip to content

Techniques

Of course, a complex selection and transformation language will always result in additional evaluation time in comparison to writing raw code in the host language. Our target is, at least, to reach an evaluation performance factor of \(\leq 5\) (in relation to raw code).1 In general, performance is enhanced by

  • taking the compilation approach to avoid AST interpretation
  • not wrapping all evaluation nodes as sequences, instead passing through single objects
  • not materializing sequences (as arrays), instead only use of iterators
  • inlining expressions to a great extent

Benchmarks

Basic

The following benchmark was performed with library benchmark (nodejs). The input object was { a: { i: 1, b: { c: 99 } } } and the expression a.b.c. Note that top wrapping2 was deactivated for apath, i.e. only the pure evaluation of the compiled expression was performed. The main reasons for the performance ratio of ~1.2 are runtime checks regarding the property names.

basic 
apath: 83,452,522 ops/sec (72 runs sampled)
raw: 96,531,790 ops/sec (78 runs sampled)
------
min Ratio: 1.244
max Ratio: 1.186
Ratio: 1.214

  1. This correlates with the typical range of 1.5 to 5 comparing functional and imperative languages like Haskell resp. C++. Basic operations can even achieve a ratio of ~1.2 . ↩

  2. Deactivated top wrapping means that the first solution is taken regardless of whether it is an iterator or a simple object. ↩