Can search script avoid hashtable lookups for field access?

[jpountz]

Take this search script: Math.abs(doc['field'].value). On every document, we will call LeafDocLookup.get which mostly fetches script doc values for the field field in a hashtable and advances it to the current document. The hashtable lookup feels a bit unnecessary since we will always return the same ScriptDocValues object on a per-segment basis, is there a way we could avoid it? A hashtable lookup may look lightweight, but when everything that you do in your script is reading a doc value and applying a cheap function like Math.abs, it might not be negligible?

[nik9000]

I think it is possible and probably dovetails into any work we would do to remove some of the hidden casts as well. I don't know the scheduling for something like that though.

[jdconrad]

This can be explored more once we break apart the analysis step into a multi-pass compiler.

[jtibshirani]

I looked into this when debugging the performance of script_score queries. The summary: the hash lookup can indeed contribute to latency, even when loading a single hard-coded field. There is also overhead from using Painless itself.

Our rally benchmarks include a comparison of a function_score and script_score query that compute the same result. Here’s the script query:

"query": {
  "script_score": {
    "query": {
      "match_all": {}
    },
    "script": {
      "source": "Math.log10(doc['population'].value * 1.2 + 2)"
    }
  }
}

Current performance
Scripting is ~30% slower.

| 50th percentile service time | field_value_function_score | 22.1627 | ms |
| 95th percentile service time | field_value_function_score | 22.5731 | ms |

| 50th percentile service time | field_value_script_score | 29.4205 | ms |
| 95th percentile service time | field_value_script_score | 30.0251 | ms |

Only load doc values once
Using this hacky branch, we load doc values for ‘population’ once, and always return them instead of performing a hash lookup. Now scripting is ~20% slower.

| 50th percentile service time | field_value_function_score | 20.2305 | ms |
| 95th percentile service time | field_value_function_score | 21.5232 | ms |

| 50th percentile service time | field_value_script_score | 24.483 | ms |
| 95th percentile service time | field_value_script_score | 25.679 | ms |

Use a custom script engine
The same branch defines a HackyScriptEngine that just computes the mathematical expression directly. It builds off the doc values hack, so this is an combined improvement. This seems to close the performance gap.

| 50th percentile service time | field_value_function_score | 19.8072 | ms |
| 95th percentile service time | field_value_function_score | 20.6771 | ms |

| 50th percentile service time | field_value_script_score | 19.9949 | ms |
| 95th percentile service time | field_value_script_score | 21.1168 | ms |