You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a previous re-scale attempt, it was discovered that using merge on some operations to simulate large row counts appears to cause periodic large regressions. For example, doing an update().sum_by() without merges at high scale produces relatively low variability between test runs. But doing the same operation with merge copies at the same scale (# or rows) produces consistent performance most of the time, but occasional large drops in rate for the test. (See chart below.)
Difference in rates between merged and not-merged is expected, while large differences in variability is not
Investigate the drops with perfmon tables and java flight recorder
Understand differences in GC characteristics between normal and regression runs for the same bits and test
Look at possible divergences in compilation paths
Chart for "Update-Sum- 2 Calcs Using 2 Cols":
Running 100 iterations on my laptop (110G heap w/ 24 CPU threads)
Each benchmark runs 640M rows
Each series name says how many merges it took to get 640M rows
Even 1 merge (320M x 2) causes large periodic regression
Merge does introduce an extra layer, so the slower times are expected, but the wild periodic swings don't make sense to me
from deephaven import perfmon as perf
qpl = perf.query_performance_log()
qpl_tree = perf.query_performance_tree_table()
qopl= perf.query_operation_performance_log()
qopl_tree = perf.query_operation_performance_tree_table()
Could introduce a named nugget that would create a QOPL line for all instrumented operations to roll up into.
io.deephaven.engine.table.impl.perf.QueryPerformanceRecorder#getInstance
io.deephaven.engine.table.impl.perf.QueryPerformanceRecorder#getNugget(java.lang.String)
(Nuggets are closeable)
In a previous re-scale attempt, it was discovered that using
merge
on some operations to simulate large row counts appears to cause periodic large regressions. For example, doing anupdate().sum_by()
without merges at high scale produces relatively low variability between test runs. But doing the same operation with merge copies at the same scale (# or rows) produces consistent performance most of the time, but occasional large drops in rate for the test. (See chart below.)Chart for "Update-Sum- 2 Calcs Using 2 Cols":
Default Deephaven Properties
Use the perfmon tables
Could introduce a named nugget that would create a QOPL line for all instrumented operations to roll up into.
Tips:
The text was updated successfully, but these errors were encountered: