Match struct fields via case folding about schema HOT 2 CLOSED

I was taking a peek into how both these packages are implemented. It seems there is a small difference in how the cache is implemented. For schema, the cache uses a map to lookup the actual field. In encoding/json, they keep a slice of fields for each type.

I think one way to achieve the same behavior with field name matching can be to always treat their aliases in lower case. So when we put a field info in the cache, we put it against a lower-cased alias. When we lookup from the cache, we strings.ToLower() the alias, and then lookup.

I was worried about how this might affect the performance. So I wrote a small benchmark func based on TestAll():

v := map[string][]string{
    // Same as TestAll()
}

b.ResetTimer()

for i := 0; i < b.N; i++ {
    s := &S1{}
    _ = NewDecoder().Decode(s, v)
}

Current implementation:

BenchmarkAll       20000         96977 ns/op       15057 B/op        314 allocs/op

Using strings.ToLower():

BenchmarkAll       20000         97152 ns/op       14854 B/op        316 allocs/op

This is done by simply changing two lines in cache.go. But I think this is not really an ideal solution, since we are trying to create a lowercase version of the alias string every time we look for a field in the cache.

The other way, if I understand this correctly, would be to use a slice of fields instead of a map in the cache (similar to encoding/json). To lookup, we loop over the slice and use the strings.EqualFold to match the alias in structInfo.get().

So I tried that too.

Using slice, instead of map and strings.EqualFold():

BenchmarkAll       20000         99610 ns/op       15108 B/op        315 allocs/op

Should mention that the rest of the tests still pass for both solutions.

So, it's either time, or memory, that we are compromising here.

Let me know what you think. And if you want, I can then send you a pull request for this.

from schema.

Thanks for having a thorough look in to this, I haven't had a chance to review the code in depth, but probably the approach taken by the json package would be best.

from schema.