Hi, On Friday, June 21, 2013, Michael Dürig wrote: > > AFAICS the call to DBCursor.hasNext seems to be the bottleneck here.
I'd look higher up the stack. The AbstractNodeState.compareAgainstBaseState() method exists as an unoptimised fallback, so having it show up in a performance bottleneck is a sign of a missing implementation-specific optimised version of the comparison. Figuring out how to avoid the fallback in this case should solve the issue. BR, Jukka Zitting
