[llvm-commits] [llvm] r158586 - /llvm/trunk/include/llvm/ADT/DenseMap.h

[Chandler Carruth]

On Fri, Jun 15, 2012 at 7:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Jun 15, 2012, at 6:18 PM, Chandler Carruth wrote:
>
> This is pretty ugly, but it allows the super class to change the
> representation of these values, which will be key for doing
> a SmallDenseMap.
>
> Suggestions on better method structuring / naming are welcome, but keep
> in mind that SmallDenseMap won't have an 'unsigned' member to expose
> a reference to... =/
>
>
> Do we have any use cases where a DenseMap would be better than a
> SmallDenseMap? It's hard to think of cases where std::vector is better than
> SmallVector.
>

The one that jumps to mind is when we the map will have one of two states:
a reasonable number of entries or zero entries. Especially if these maps
are inside of other datastructures, we don't want to pay inline storage for
all the empty maps.

One unfortunate thing is that the small variation will only be able to
store a single bucket for free, and the cost will be a branch along the hot
path of most operations. We could remove the branch, but that will cause us
to be able to store *no* buckets for free in terms of storage.

We'd need to run a lot of benchmarks I suspect to be able to tell if
DenseMap<X, Y> could be equivalent to SmallDenseMap<X, Y, 1>... but if we
get there, I'll be happy to rip out a bunch of code. =] Keeping both seems
useful for the transitional period anyways.


> It seems this could be a lot simpler if you didn't have to preserve the
> original DenseMap exactly.
>
> /jakob
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120615/d97e0466/attachment.html>