MeiliSearch/milli/src/update
meili-bors[bot] ee62d9ce30
Merge #4845
4845: Fix perf regression facet strings r=ManyTheFish a=dureuill

Benchmarks between v1.9 and v1.10 show a performance regression of about x2 (+3dB regression) for most indexing workloads (+44s for hackernews).

[Benchmark interpretation in the engine weekly meeting](https://www.notion.so/meilisearch/Engine-weekly-4d49560d374c4a87b4e3d126a261d4a0?pvs=4#98a709683276450295fcfe1f8ea5cef3).

- Initial investigation pointed to #4819 as the origin of the regression.
- Further investigation points towards the hypernormalization of each facet value in `extract_facet_string_docids`
- Most of the slowdown is in `normalize_facet_strings`, and precisely in `detection.language()`.

This PR improves the situation (-10s compared with `main` for hackernews, so only +34s regression compared with `v1.9`) by skipping normalization when it can be skipped.

I'm not sure how to fix the root cause though. Should we skip facet locale normalization for now? Cc `@ManyTheFish` 

---

Tentative resolution options:

1. remove locale normalization from facet. I'm not sure why this is required, I believe we weren't doing this before, so maybe we can stop doing that again.
2. don't do language detection when it can be helped: won't help with the regressions in benchmark, but maybe we can skip language detection when the locales contain only one language?
3. use a faster language detection library: `@Kerollmops` told me about https://github.com/quickwit-oss/whichlang which bolsters x10 to x100 throughput compared with whatlang. Should we consider replacing whatlang with whichlang? Now I understand whichlang supports fewer languages than whatlang, so I also suggest:
4. use whichlang when the list of locales is empty (autodetection), or when it only contains locales that whichlang can detect. If the list of locales contains locales that whichlang *cannot* detect, **then** use whatlang instead.

---

> [!CAUTION]
> this PR contains a commit that adds detailed spans, that were used to detect which part of `extract_facet_string_docids` was taking too much time. As this commit adds spans that are called too often and adds 7s overhead, it should be removed before landing.

Co-authored-by: Louis Dureuil <louis@meilisearch.com>
Co-authored-by: ManyTheFish <many@meilisearch.com>
2024-08-19 06:29:48 +00:00
..
facet Make milli use edition 2021 (#4770) 2024-07-09 17:25:39 +02:00
index_documents Merge #4845 2024-08-19 06:29:48 +00:00
available_documents_ids.rs make clippy happy 2024-07-10 10:06:59 +02:00
clear_documents.rs Implement localized attributes settings 2024-07-25 10:51:27 +02:00
del_add.rs Make milli use edition 2021 (#4770) 2024-07-09 17:25:39 +02:00
indexer_config.rs Introduce the ThreadPoolNoAbort wrapper 2024-04-24 16:40:12 +02:00
mod.rs fix PR comments 2024-02-13 15:19:01 +01:00
settings.rs Introduce Setting::some_or_not_set 2024-07-25 12:01:52 +02:00
update_step.rs Implement documents format 2021-09-21 16:58:33 +02:00
word_prefix_docids.rs Remove puffin usage 2024-05-27 15:59:14 +02:00
words_prefix_integer_docids.rs Remove puffin usage 2024-05-27 15:59:14 +02:00
words_prefixes_fst.rs Remove puffin usage 2024-05-27 15:59:14 +02:00