Affects Version/s: None
Fix Version/s: BLAZEGRAPH_2_2_0
This ticket is to assess the performance benefit/loss realized when using the native heap to store the intermediate solutions. The comparison might be analytic mode vs non-analytic mode, or we might compare non-analytic mode with native heap storage for the intermediate solutions.
Note: For some benchmarks (govtrack) we are already using the analytic mode, so the comparison would be analytic mode in
BLZG-533 (with native heap for intermediate solutions) vs analytic mode for master. This would be addressed by the other benchmarking ticket automatically.
Note: I am expecting that performance of the analytic mode is slightly less overall, but that as increased pressure is exerted on the JVM, the analytic mode (with native heap storage for the intermediate solutions) will scale better than the managed object heap mode and might do better on an absolute basis as well. Certainly, in cases where the JVM would be driven into GC OH with the non-analytic mode, the analytic mode should significantly out-perform the non-analytic mode.
BLZG-533 removes one of the key remaining sources of GC pressure, which are the intermediate solutions on the managed object heap.
There is still a remaining source of GC pressure for queries which produce high cardinality outputs at a high rate of production. The final query outputs are still stored on the managed object heap. BLZG-1968 would address this. The challenge with that ticket is ensuring that we have a suitable producer / consumer pattern such that the query engine can swiftly unburden itself of the query, by streaming the results into native memory, while at the same time ensuring that the client does not observed increased latency for low cardinality queries.