Flattener performance

[timbray]

@yosiat has been working on flatten_json.go and has lots of interesting findings. He requested that I enable discussions… I was able to launch one, so maybe that auto-enables them?

Since the cost of flattening is typically ~50% of the matchesForJSONEvent, it's a good place to invest in improving Quamina's performance!

[yosiat]

Context:

During this PR I found our that not using step (which increases the cursor in event and check bounds) and ch (which returns the current byte from the event, simple array lookup) can help improve performance.

More specifically on:

• skipBlock I just manually inlined those methods
• skipStringValue I took slice of the event (data) and used local counter (i) and accessed the slice of the event

Here is the benchmark that compares using step & ch comparing to the merged code:

benchmark                                                old ns/op     new ns/op     delta
Benchmark_JsonFlattener_ContextFields-10                 9062          12211         +34.75%
Benchmark_JsonFlattener_MiddleNestedField-10             10730         13619         +26.92%
Benchmark_JsonFlattener_LastField-10                     9570          12598         +31.64%
Benchmark_JsonFlattner_Evaluate_ContextFields-10         9487          12607         +32.89%
Benchmark_JsonFlattner_Evaluate_MiddleNestedField-10     11122         14021         +26.07%
Benchmark_JsonFlattner_Evaluate_LastField-10             9873          12893         +30.59%

benchmark                                                old allocs     new allocs     delta
Benchmark_JsonFlattener_ContextFields-10                 3              3              +0.00%
Benchmark_JsonFlattener_MiddleNestedField-10             4              4              +0.00%
Benchmark_JsonFlattener_LastField-10                     2              2              +0.00%
Benchmark_JsonFlattner_Evaluate_ContextFields-10         13             13             +0.00%
Benchmark_JsonFlattner_Evaluate_MiddleNestedField-10     13             13             +0.00%
Benchmark_JsonFlattner_Evaluate_LastField-10             9              9              +0.00%

benchmark                                                old bytes     new bytes     delta
Benchmark_JsonFlattener_ContextFields-10                 48            48            +0.00%
Benchmark_JsonFlattener_MiddleNestedField-10             64            64            +0.00%
Benchmark_JsonFlattener_LastField-10                     32            32            +0.00%
Benchmark_JsonFlattner_Evaluate_ContextFields-10         480           480           +0.00%
Benchmark_JsonFlattner_Evaluate_MiddleNestedField-10     488           488           +0.00%
Benchmark_JsonFlattner_Evaluate_LastField-10             312           312           +0.00%

Investigation:

It was really interesting that not using this methods and the two options I presented gave interesting performance improvements, and we thought maybe we can leverage this knowledge and using it in the whole flattener.

I conducted some benchmarks, which essentially scans a json byte array ([]byte) and counts the number of quotes ("), with multiple methods, the benchmarks and results are published here: https://github.com/yosiat/quotes-count

The reason that step & ch are slower is essentially because they are on the heap, while the other example is on stack. Because of obvious reasons we can move flattenJson to be on stack.

The interesting stuff I found is:

• _QuotesCount_Heap_For_EventIndex is doing for eventIndex < len(event) and incrementing eventIndex, on M1 is shows performance benefit while on Intel it doesn't.
• _QuotesCount_Heap_Next - Instead of doing for without conditions, I added a next method which just checks the eventIndex - on M1 it's faster, but on Intel it's slower - so we can't use this trick.

I checked other json parsers on how they managing their state, and found that it splits:

• Most of them is doing the same as flattenJson - referencing their state with heap pointers.
• Others have each method accept the rest of payload to process and return an offset, so for example, reading an array will be offset, values, err := fj.readArray(fj.event[i:]) and then upon success do i += offset , so in both methods the index is on the stack, same as the event.

I can do POC of the second option to see how much it improves the performance, but it will be have worse DX and be more error prone. so I am not sure if the cost (performance vs complexity) will be worth it.

Before going to POC, I would to hear an opinion about this investigation results & does the complexity is something we want to consider or it doesn't worth it.

Some note: Regarding this issue: #113, the next thing I am planning to work is doing a PR with my "Paths Index" idea that would allow us:

• Reduce allocations of building paths to zero (since we will do them during patterns addition)
• Stop parsing early if we fetched all fields already.