Nikita Amelchev created IGNITE-29275:
----------------------------------------
Summary: Remove unused end time tracking from cache futures
Key: IGNITE-29275
URL: https://issues.apache.org/jira/browse/IGNITE-29275
Project: Ignite
Issue Type: Improvement
Reporter: Nikita Amelchev
Assignee: Nikita Amelchev
Every cache future (get, atomic update, lock, transaction prepare and finish)
records its completion time in a volatile field on {{{}onDone{}}}, but
{{{}GridCacheFuture.duration(){}}}, the only reader of that field, has no
callers. The field enlarges every future instance and adds a volatile write to
every completion on the hot path.
h3. Benchmarks
JMH, existing `JmhCacheBenchmark` (`get`, `put`) and `JmhCacheLocksBenchmark`
(`cacheLock`): client + 2 server nodes
in one JVM, `backups=1`, `FULL_SYNC`, 4 threads. Allocation is
`gc.alloc.rate.norm` over all nodes, measured with C1
(`-XX:TieredStopAtLevel=1`) where it is deterministic; 2 forks per variant in
alternating order.
|Operation|Before, B/op|After, B/op|Diff, B/op|
|—|—|—|—|
|`get`, ATOMIC|3167|3159|−8|
|`put`, ATOMIC|5752|5734|−18|
|`lock()` + `unlock()`, TRANSACTIONAL|14732|14716|−16|
|`put`, TRANSACTIONAL (implicit tx)|21344|21307|−37|
Each cache future taking part in the operation loses 8 bytes (e.g.
`GridPartitionedSingleGetFuture` 96 → 88,
`GridNearLockFuture` 160 → 152 by JOL). With C2 the same −8 / −15 B/op are seen
for `get` / atomic `put` in forks with
the same JIT mode, while for transactional `put` and locks the fork-to-fork
variance hides the difference.
Throughput didn't change measurably: patched forks stay within the spread of
the base ones.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
