3 ms·
We're using similar techniques to parse and merge JSON objects, which could be applied to this problem as well. Essentially, you could index the whole input int
by jensneuse 3y ago
We're using similar techniques to parse and merge JSON objects, which could be applied to this problem as well. Essentially, you could index the whole input into an AST and the. Traverse the AST to find the data you're looking for. In our case, we're not just doing that, but recursively merge JSON objects at the AST level which is a lot faster than merging the actual data. The full blog post on the problem and solution can be found here: https://wundergraph.com/blog/astjson_high_performance_json_transformations_in_golang https://wundergraph.com/blog/astjson_high_performance_json_t...
- kiitos 3y agohttps://github.com/wundergraph/graphql-go-tools/blob/dcd50bd528aba3eba9e553203150724dbe193fdf/v2/pkg/astjson/astjson_test.go#L448-L477 https://github.com/wundergraph/graphql-go-tools/blob/dcd50bd... Each iteration of this benchmark measures the aggregate performance of - 1x ParseObject - 3x AppendObject - 3x MergeNodesWithPath - 1x PrintNode - 1x bytes.Equal comparison of two byte slices So the benchmark isn't really measuring MergeNodesWithPath, it's measuring a much larger composite operation, which includes (multiple) calls to MergeNodesWithPath but also all of the above listed calls as well. If you want to measure MergeNodesWithPath, you would need to have each iteration of the loop do a single MergeNodesWithPath call, on the same JSON method receiver, and with the same input parameters. edit: similar issues exist in many/most of the other benchmark functions as well