# \[elasticserach performance\] Elasticsearch-spend-all-time-in-build-scorer

**URL:** <https://discuss.elastic.co/t/elasticserach-performance-elasticsearch-spend-all-time-in-build-scorer/113717>\
**Category:** Elasticsearch\
**Created:** [January 2, 2018, 4:24am UTC](https://discuss.elastic.co/t/elasticserach-performance-elasticsearch-spend-all-time-in-build-scorer/113717 "2018-01-02T04:24:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Holygost](https://avatars.discourse-cdn.com/v4/letter/h/b782af/32.png) [@Holygost](https://discuss.elastic.co/u/Holygost)\
**Post date:** [January 2, 2018, 4:24am UTC](https://discuss.elastic.co/t/elasticserach-performance-elasticsearch-spend-all-time-in-build-scorer/113717/1 "2018-01-02T04:24:27Z")

</div>

I use ES 5.5.0，and I have the same problem that the time almost cost at build\_scorer, detail as follow:

> <https://stackoverflow.com/questions/47885899/elasticsearch-spend-all-time-in-build-scorer>

---

<div class="post-metadata">

**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\
**Post date:** [January 5, 2018, 2:21pm UTC](https://discuss.elastic.co/t/elasticserach-performance-elasticsearch-spend-all-time-in-build-scorer/113717/2 "2018-01-05T14:21:56Z")

</div>

Is the field `"views"` mapped as a numeric of some variety?

In ES 5.x, numerics use a new datastructure (BKD tree). This allows better compression, faster numeric operations and lower memory usage... but it is not ideal for "point lookups" like a `term` query. E.g. it is designed for numeric style operations like ranges, but not single value lookups.

If that field is really an identifier of some type, where you mainly do point lookups, you should re-map it as a `keyword`. Keyword fields are optimized for single-term lookups like you're doing.

More info: [https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html#\_map\_identifiers\_as\_literal\_keyword\_literal](https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html#_map_identifiers_as_literal_keyword_literal)

To dive a bit more into technicals, the BKD datastructure doesn't support sorted iteration, so it has to collect all matches, sort the array and then return an iterator to that sorted array (paraphrasing). That process happens during the `build_scorer` step, which is why it is slow and you see it showing up in the profiler output. This process isn't bad when dealing with numeric ranges, but can get expensive when asking for a bunch of individual points.

2.x didn't have BKD trees, hence the difference in performance.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [February 2, 2018, 2:22pm UTC](https://discuss.elastic.co/t/elasticserach-performance-elasticsearch-spend-all-time-in-build-scorer/113717/3 "2018-02-02T14:22:03Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.