HistoryQuick provider (a.k.a. HistoryQuickProvider, HQP) has a cache to make searching faster.
https://cs.chromium.org/chromium/src/components/omnibox/browser/url_index_private_data.h?type=cs&l=165-195

One would think this should help most at times when HQP needs to run a duplicate search. 
In these cases, naively one would think we'd have an exact cache hit and short-circuit the search.

It doesn't help in some of these cases before of this fragment:

https://cs.chromium.org/chromium/src/components/omnibox/browser/url_index_private_data.cc?type=cs&l=228-233
  if (history_ids_were_trimmed) {
    // If we trim the results set we do not want to cache the results for next
    // time as the user's ultimately desired result could easily be eliminated
    // in the early rough filter.
    search_term_cache_.clear();
  }

If too many suggestions matched the input, it's not stored in the cache.

Hmmmm...


By the way, this *does* not affect first keystroke responsiveness because
(i) the cache only stores the list of URLs that match the input, not their scores.  (Scoring is always re-run regardless of a cache hit in the index.)
(ii) HQP's data structures already have a direct lookup map for single-character inputs.  In other words, they're effectively already cached in the sense of how this cache works.
 

HistoryQuick provider (a.k.a. HistoryQuickProvider, HQP) has a cache to make searching faster.
https://cs.chromium.org/chromium/src/components/omnibox/browser/url_index_private_data.h?type=cs&l=165-195

One would think this should help most at times when HQP needs to run a duplicate search. 
In these cases, naively one would think we'd have an exact cache hit and short-circuit the search.

It doesn't help in some of these cases because of this fragment:

https://cs.chromium.org/chromium/src/components/omnibox/browser/url_index_private_data.cc?type=cs&l=228-233
  if (history_ids_were_trimmed) {
    // If we trim the results set we do not want to cache the results for next
    // time as the user's ultimately desired result could easily be eliminated
    // in the early rough filter.
    search_term_cache_.clear();
  }

If too many suggestions matched the input, it's not stored in the cache.

Hmmmm...


By the way, this *does* not affect first keystroke responsiveness because
(i) the cache only stores the list of URLs that match the input, not their scores.  (Scoring is always re-run regardless of a cache hit in the index.)
(ii) HQP's data structures already have a direct lookup map for single-character inputs.  In other words, they're effectively already cached in the sense of how this cache works.