Reimplement NamedTuble#fetch(String) using a Trie

[lbguilherme]

Instead of comparing each string key one by one, build a Prefix Tree at compile-time and make a single comparison per char. This improves performance by 16x on large named tuples and about 1.5x on smaller ones.

Large benchmark: https://gist.github.com/lbguilherme/c7249c408d2a226bdbb6892dda5e9ab2
Small benchmark: https://gist.github.com/lbguilherme/7dba63104c4b44d3adcd5bcc9f9d7c20

See #3143 and #2966

[bcardiff]

I like this 👍 . Since you have a branch in the logic for more than 16 keys of the same size I would say we need some specs to cover that. Just to be sure it does not break in the future.

Let's see if some else agree with this before.

[asterite]

I'm not sure about this, a named tuple is not to be used as a hash. They represent named arguments, to a method, and methods usually don't have many arguments. I'd rather have a short and simple implementation, even if a bit slower, than a complex, macro heavy one.

I'd need to find a real use case where big named tuples are used, and indexed with an arbitrary key.

[straight-shoota]

If you have such a big datastructure, I don't see a point in using a NamedTuple as well.
A Hash has about the same lookup speed anyway, in this example it's even faster. But I had to cut down the number of entries in the NamedTuple since the compiler maxes at 300.

check every key   2.99  (334.04ms) (±24.93%) 341.02× slower
    trie lookup  34.87  ( 28.68ms) (± 9.12%)  29.28× slower
           hash   1.02k (979.55µs) (±11.60%)        fastest

https://gist.github.com/straight-shoota/cb903575c6dd86d1c6c86c372d842666

[akzhan]

NamedTuple looks like returning value pattern, and eats less memory afair.

No more.

[asterite]

Closing because too complex, and NamedTuple shouldn't normally be used.