https://bugs.openldap.org/show_bug.cgi?id=10406
Issue ID: 10406
Summary: Write regression since 0.9.19
Product: LMDB
Version: 0.9.33
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
I maintain LmdbJava, a Java wrapper for LMDB. We have an extensive benchmark
suite covering read, cursor, and write pathways, with isolated testing of LMDB
versions from 0.9.17 through 0.9.33.
Results: https://lmdb-benchmark.lmdbjava.org/
==============================================
SUMMARY
==============================================
Read performance: 0.9.33 consistently outperforms 0.9.17 across all read
benchmarks.
Write performance: Consistent regression since 0.9.19:
----------------------------------
Tag ms/op vs 0.9.17
----------------------------------
LMDB_0.9.17 75.790 baseline
LMDB_0.9.18 74.909 -1.2%
LMDB_0.9.19 81.404 +7.4%
LMDB_0.9.20 83.459 +10.1%
LMDB_0.9.21 83.237 +9.8%
LMDB_0.9.22 83.027 +9.5%
LMDB_0.9.23 82.870 +9.3%
LMDB_0.9.24 82.952 +9.4%
LMDB_0.9.27 82.989 +9.5%
LMDB_0.9.28 83.025 +9.5%
LMDB_0.9.29 83.063 +9.6%
LMDB_0.9.30 83.237 +9.8%
LMDB_0.9.31 88.419 +16.7%
LMDB_0.9.33 83.304 +9.9%
Excluding 0.9.31 as an outlier, write performance degraded by approximately 9%
from 0.9.20 and has remained at that level through 0.9.33.
==============================================
BENCHMARK DETAILS
==============================================
The write benchmark sequentially inserts 1,000,000 entries (100-byte values,
4-byte integer keys) into a database opened with MDB_INTEGERKEY, using a single
cursor with MDB_APPEND flag. The benchmark includes 2 warmup iterations and 3
measurement iterations of 120 seconds each.
==============================================
ANALYSIS
==============================================
Reviewing the commit history, the regressions appear linked to correctness
fixes:
- 0.9.19: ITS#8406 (xcursor fixup after cursor_del)
- 0.9.20: ITS#8557 (cursor_last and C_EOF handling)
Both issues added cursor state management overhead in write-heavy code paths.
==============================================
REQUEST
==============================================
Could you please reproduce this regression using a native C benchmark to
confirm it's not JNI-specific? If confirmed, this may be a necessary
performance/correctness tradeoff given that most LMDB workloads are read-heavy.
--
You are receiving this mail because:
You are on the CC list for the issue.
