Is there a hash-map implementation optimized to favor key lookups based on frequency (if key is referenced the most then it is searched first)?

Question

I have started to play around with HTTP3 which relies on QUIC for transport. I have noticed that I very often have a finite number of Web Transport sessions stream data continuously along side burst-y HTTP3 REST calls. At the QUIC level, all of these streams are going over the same connection and are demultiplexed via a go hash map by Stream ID. This is working fine, but I was wondering about scaling; specifically the Web Transport streams are typically more latency sensitive than the REST API calls. More generally, I find that I want to prioritize the active streams that have sent the most data.

Focusing on the go hashmap that treats all keys equally, is there any hash table that prioritizes keys that get referenced the most? So if Stream N gets referenced 100K times and Stream M gets referenced 10 times, the hash algorithms checks for a match of N before M?

Update

To clarify QUIC's connection/stream model more (and ignore crypto for now):

• A QUIC connection, ignoring crypto, can be thought of as a typical UDP connection. It is over this that QUIC Frames get passed.
• QUIC Streams act like TCP connections, data regarding a stream is passed over the connection in a QUIC Stream Frame with the Stream ID in the header.

So a QUIC connection allows for the passing of QUIC Frames, and both client and server must identify which frames belong to which streams (via Stream ID mapped to an internal context) and pass the data along. to local conversation handlers.

Update #2

As stated in the comments by other users, implementing this very well may not be worth the overhead, but here is an unoptimized version of what I am talking about:

type WeightedMap []WeightedEntry

type WeightedEntry struct{
    refcount uint64
    Key int //streamID
    Value interface{} // basically a pointer in go
}

func (w *WeightedMap)Get(key int) (out interface{}){
    vm := *w
    for i := range vm{
       if vm[i] == key{
         vm[i].refcount++
         out = vm[i].Value
         break
       }
    }
    if out != nil{
      sort.SliceStable(wm, func(i, j int) bool {
          return wm[i].refcount > wm[i].refcount
      })
    }
}

A better version could at least greatly improve the Sort step by just looking at the entry in question and its neighbor with a higher index. Just wanted to convey a rough idea.

Answer 1

A hash table takes a key, calculates a hash value for the key, and maps the hash value to a sequence of indexes into the table. The mapping key -> hash value is fixed at least while the hash table exists.

Usually the number of possible hash values is huge; it might be $2^{64}$ which means you won't have the same hash value twice in practice. But each hash produces a sequence of indexes, and many keys might use the same index.

Usually you keep the hash table substantially larger than the number of values stored, so if the indexes were random, you would find a key very often at the first index, quite often at the second index, rarely at the third or later index. So the number of indexes to check should be small anyway; otherwise you increase the table size. And skipping the wrong index is very fast: You store the hash key with the value in the hash table, so when you check index i, all you do is to compare the hash values which are stored in the table or just computed. This is very fast.

The things costing substantial effort are: 1. Calculate the hash value for the key to look up. 2. When an index with the right hash value is found, compare the keys. Everything else has minimal execution time, so there's very little need to improve the time for the keys used most often.