Avoid HashMap in ShardQueue

[GnomedDev]

This avoids hashing costs, is probably more cache efficient, and avoids storing duplicate information (length of buckets and max concurrency are equal).

[mkrasnitski]

Actually, we could even use a regular Vec to avoid pulling in extra machinery. Under the hood, VecMap uses a Vec<Option<V>>, but storing VecDeque::new() is pretty much the same semantically as storing None, so just making it a Vec<VecDeque<ShardId>> would work.

[GnomedDev]

Sure, good idea.

[mkrasnitski]

Looking at your changes in small-fixed-array 0.3, it seems the type inference for indices is a problem. I don't think it makes sense to provide more than one implementation of Index. Sticking with usize is probably best for now.

[GnomedDev]

I definitely see that, but I believe that the type inference problems are worth it to make indexing using the length type provided work.

[mkrasnitski]

I definitely see that, but I believe that the type inference problems are worth it to make indexing using the length type provided work.

I don't quite understand the benefit of indexing with the length type. What does it provide?

[GnomedDev]

If the type for indexing does not match the type returned from len, a lot of basic patterns become a pain. Further discussion on this should be done on the small-fixed-array repo, as this is not the right place for it.