V6 future Changes about validator

[deankarn]

Ok v6 Benchmarks ( old v5 thrown in for comparison )

Old v5 no caching

$ go test -cpu=4 -bench=. -benchmem=true
PASS
BenchmarkValidateField-4             3000000           473 ns/op          80 B/op          4 allocs/op
BenchmarkValidateStructSimple-4       300000          5010 ns/op        1200 B/op         33 allocs/op
BenchmarkTemplateParallelSimple-4    1000000          2185 ns/op        1200 B/op         33 allocs/op
BenchmarkValidateStructLarge-4         50000         28706 ns/op        6980 B/op        201 allocs/op
BenchmarkTemplateParallelLarge-4      200000         14362 ns/op        6983 B/op        201 allocs/op

New v6 no caching

$ go test -cpu=4 -bench=. -benchmem=true
PASS
BenchmarkField-4                     3000000           524 ns/op         128 B/op          5 allocs/op
BenchmarkFieldOrTag-4                 500000          2808 ns/op         180 B/op          7 allocs/op
BenchmarkStructSimple-4               300000          4246 ns/op        1016 B/op         31 allocs/op
BenchmarkStructSimpleParallel-4      1000000          1537 ns/op        1016 B/op         31 allocs/op
BenchmarkStructComplex-4              100000         23908 ns/op        5079 B/op        183 allocs/op
BenchmarkStructComplexParallel-4      200000          8845 ns/op        5081 B/op        183 allocs/op

Summary

Overall better performance, lower B/op and less allocations...except for Single Field validations which increased slightly; However to note the new v6 code is vastly simplified, streamlined and more maintainable.

how vastly you ask, well the main validator.go file went from 989 to 453 lines enough said.

[deankarn]

Added just ValidationErros caching, more to come

$ go test -cpu=4 -bench=. -benchmem=true
PASS
BenchmarkField-4                     3000000           461 ns/op          80 B/op          4 allocs/op
BenchmarkFieldOrTag-4                 500000          2756 ns/op         132 B/op          6 allocs/op
BenchmarkStructSimple-4               300000          4362 ns/op         971 B/op         30 allocs/op
BenchmarkStructSimpleParallel-4      1000000          1595 ns/op         971 B/op         30 allocs/op
BenchmarkStructComplex-4               50000         24242 ns/op        5051 B/op        182 allocs/op
BenchmarkStructComplexParallel-4      200000          8900 ns/op        5050 B/op        182 allocs/op

[deankarn]

Added back tag parsing caching

$ go test -cpu=4 -bench=. -benchmem=true
PASS
BenchmarkField-4                     5000000           321 ns/op          16 B/op          1 allocs/op
BenchmarkFieldOrTag-4                 500000          2566 ns/op          20 B/op          2 allocs/op
BenchmarkStructSimple-4               500000          3233 ns/op         553 B/op         14 allocs/op
BenchmarkStructSimpleParallel-4      1000000          1182 ns/op         554 B/op         14 allocs/op
BenchmarkStructComplex-4              100000         19979 ns/op        3234 B/op        102 allocs/op
BenchmarkStructComplexParallel-4      200000          7083 ns/op        3235 B/op        102 allocs/op

[deankarn]

Added back struct caching, but now am torn...although it helps with B/ap and allocs/op for struct validation it absolutely kills parallel ns/op..just compare with above.

$ go test -cpu=4 -bench=. -benchmem=true
PASS
BenchmarkField-4                     5000000           316 ns/op          16 B/op          1 allocs/op
BenchmarkFieldOrTag-4                 500000          2466 ns/op          20 B/op          2 allocs/op
BenchmarkStructSimple-4               500000          3079 ns/op         513 B/op         10 allocs/op
BenchmarkStructSimpleParallel-4       500000          3229 ns/op         514 B/op         10 allocs/op
BenchmarkStructComplex-4              100000         17365 ns/op        2943 B/op         66 allocs/op
BenchmarkStructComplexParallel-4      100000         13958 ns/op        2946 B/op         66 allocs/op

[deankarn]

which is more important faster library or less garbage collection, guess I'll have to see how long garbage collection takes, if it's more than the time added to parallel ns/op then it's worth the performance hit as in actuality it would be faster, just the benchmarks wouldn't reflect that.

[deankarn]

OK so decided to leave struct caching out, speed and scalability is the goal of the library and struct caching slows the speed and scalability and so a few more allocation, IMHO, are not a big deal.

[deankarn]

v6 is now ready to rock! will be releasing after a few of the major players using the library have had a chance to review.

@manucorporat if you wanted to take a look as I think it affects your project the most

[deankarn]

Currently putting through it's paces in an internal project, and will be released soon