Attempts at speeding up StringTableBuilder

[Daniel Berlin via llvm-commits]

On Fri, Oct 14, 2016 at 11:23 AM, Rafael Espíndola via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> I have put some effort to try to speed up StringTableBuilder. The last
> thing that worked was committed as r284249.
>
> The main difficulty in optimizing it is the large number of strings it
> has to handle. In the case of xul, one of the string tables has
> 14_375_801 strings added, out of which only 1_726_762 are unique.
>

Where is time being spent?

It sounds like in this case, most of the hash lookups are hits?

It's possible to make it so there are no hash calculations that fail, but
if we aren't spending time in either:

hash misses
or
hash calculation

this is going to be hard to beat.



>
> The things I tried:
>
> * Instead of returning size_t from add, pass in a size_t* to add. This
> allows us to remember all StringRefs and only do the merging in
> finalize. This would be extra helpful for the -O2 case by not needing
> an extra hash lookup. The idea for -O1 was to avoid hash resizing and
> improve cache hit by calling StringIndexMap.reserve. Unfortunately
> given how many strings are duplicated this is not profitable.
>
> * Using a DenseSet with just an unsigned in it and a side std::vector
> with the rest of the information. The idea is that the vector doesn't
> contain empty keys, so it should be denser. This reduced the cache
> misses accessing the set, but the extra vector compensated for it.
>
> * Creating the string buffer incrementally in add. The idea is that
> then we don't need to store the pointer to the string. We can find out
> what the string is with just the offset. This was probably the most
> promising. It reduced the total number of cache misses reported by
> perf stat, but the overall time didn't improve significantly. This
> also makes -O2 substantially harder to implement. I have attached the
> patch that implements this (note that -O2 is not implemented).
>
> * Not merging constants to see if special casing them would make a
> difference. No test speeds ups by even 1%.
>
> In summary, it seems the string merging at -O1 is as fast as it gets
> short of someone knowing a crazy algorithm. At -O2 it should be
> possible to avoid the second hash lookup by passing a size_t* to add,
> but it is not clear if that would be worth the code complexity.
>
> Cheers,
> Rafael
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161016/b0514faf/attachment.html>