Repository navigation
Report bytes written per operation - #38
Merged
Merged
Conversation
Both adapters read the engine's own write counters: WAL and page bytes for HStore, JE's sequential and random write bytes for HyperGraphDB. Write workloads flush after their timed section so buffered bytes land on the right workload, and the run records the total at the end.
This was referenced Oct 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #30
Both engines already count what they write, so the adapters just read those counters:
walBytes + dataBytesWrittenfromEngineStats, which includes pages moved by compactiongetNSequentialWriteBytes() + getNRandomWriteBytes()from JE'sEnvironmentStats, which includes the log cleanerThe write workloads (ingest, updates, single commits, the large edge) record the difference before and after. Each one flushes after its timed section, with an HStore checkpoint or
Environment.sync(), so buffered bytes count against the right workload and throughput isn't affected. The counters restart on reopen, so both adapters carry the total across it. The run also stores the overall total in the header.The report gets a Resources table with bytes per operation, plus the total. Older result files render unchanged.
Smoke run at scale 1, async, one run each on a loaded machine:
Total for the run: 325.7 MiB for HStore, 548.9 MiB for HyperGraphDB.
The
latency.commitline goes with what #37 found: a single-update commit in HStore writes about 20 KiB, so the fixed cost of each commit is high. Probably the copy-on-write path in every tree the commit touches. I'll look at that separately.