ss: Remove cache-level synchronization in HT_IO
authorAlexandre Montplaisir <alexmonthy@efficios.com>
Thu, 23 Jun 2016 20:18:22 +0000 (16:18 -0400)
committerAlexandre Montplaisir <alexmonthy@efficios.com>
Tue, 5 Jul 2016 18:42:25 +0000 (14:42 -0400)
commit4790127ede4326bc6aa2098291823ca62c22b0e5
treefcb3f84b783c93ebd23cf218aa828fc3eda68025
parentd21209962bb402078b01481db075eec3411c320d
ss: Remove cache-level synchronization in HT_IO

The LoadingCache supports multi-threaded access, we can remove
the "synchronized" on the methods and only lock at the object
level whenever we need to hit the disk.

Benchmark results of the HistoryTreeBackendBenchmark comparing
the current master version and the LoadingCache + this patch:

(using System Time in all cases):

                     Master   LoadingCache + no-cache-synchro
Average
Build:               262ms             284ms
Single Queries:       15ms              12ms
Full Queries:         13ms              11ms
Query History Range: 147ms             120ms

Vertical scaling
Build:               17.77s           19.82s
Single Queries:       2.92s             3.2s
Full Queries:         4.14s            4.42s
Query History Range: 48.06s           57.03s

Horizontal scaling
Build:               10.54s            9.82s
Single Queries:       186ms            110ms
Full Queries:         157ms             86ms
Query History Range: 14.52s           13.61s

Interval distribution uniformly distributed
Build:               428ms             402ms
Single Queries:       31ms              24ms
Full Queries:         26ms              16ms
Query History Range: 368ms             443ms

Interval durations with 10 percent outliers
Build:               238ms             215ms
Single Queries:       12ms               9ms
Full Queries:         12ms               9ms
Query History Range: 120ms              92ms

Data type strings
Build:               302ms             288ms
Single Queries:       36ms              29ms
Full Queries:         27ms               8ms
Query History Range: 333ms             107ms

Data type longs
Build:               256ms             250ms
Single Queries:       16ms              13ms
Full Queries:         13ms               8ms
Query History Range: 151ms              91ms

Data type doubles
Build:               264ms             248ms
Single Queries:       18ms              14ms
Full Queries:         14ms               7ms
Query History Range: 161ms              90ms

The "vertical scaling" seem strange, but remember this is a
degenerate case where the average node usage is rounded to 0%.
The LoadingCache seems slightly less resilient to cache thrashing,
(which makes sense for LRU vs. direct-map in general) but it's
faster in all other regular use cases.

Other patches are being worked on to avoid trees with very low
node usage.

Change-Id: I96e32d99febb1dbbe7f9d2b473d15307c4b8e2e5
Signed-off-by: Alexandre Montplaisir <alexmonthy@efficios.com>
Reviewed-on: https://git.eclipse.org/r/75886
Reviewed-by: Hudson CI
Reviewed-by: Genevieve Bastien <gbastien+lttng@versatic.net>
Tested-by: Genevieve Bastien <gbastien+lttng@versatic.net>
statesystem/org.eclipse.tracecompass.statesystem.core/src/org/eclipse/tracecompass/internal/statesystem/core/backend/historytree/HT_IO.java
This page took 0.025027 seconds and 5 git commands to generate.