Open aclowkey opened 4 years ago
Yes, your hunch is right. The API is designed to support a single-pass operation on multiple paths, but at this moment the implementation executes each path serially. A while back I coded it for single-path but then there were some bugs (#47 #54 #55) that cropped up, so I switched it to what it is now. I hope to find more time in the future to bring it to it's full glory.
If someone need a fast GetMany
alternative, maybe take a look this one: https://github.com/ohler55/ojg
benchmark on 40KB json with 7 search:
cpu: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
BenchmarkGJsonSearch-16 23752 48151 ns/op
BenchmarkOJGSearch-16 123057 9234 ns/op
@Yiling-J do you have any code samples for your benchmark?
@franchb I don't keep the benchmark code, but it's very easy to write one:
obj, err := oj.ParseString(yourJsonString)
path := []string{path1, path2, path3...}
for _, p := range path {
x, err := jp.ParseString(p)
ys := x.Get(obj)
}
I'll preface by saying it's a hunch and I have no convincing argument other than my intuition and I'm not familiar with the internals of gjson.
For large JSON's GetMany will iterate through all the entire JSON and will be no more efficient than just calling Get, many, times.
I think there could be some point for optimiziation by checking if the path matches EITHER of the many paths provided. i.e.
Any thoughts?