[marcus-pousette-hp]

Before:

read remoteContiguousLength
-> scan remote bitfield from stale cached position
-> return higher value
-> cache stays stale
-> next read scans same area again

After:

read remoteContiguousLength
-> scan remote bitfield once
-> cache the verified higher value
-> next read starts from the higher value

Local bench test from before and after patch.

10k reads over a 50M-bit verified contiguous extent
before: ~51.7 ms
after:  ~2.26 ms

PR was Co-authored with AI.

[lejeunerenard]

Having a getter with side effects is tenuous as getters imply only reading values.

Can we apply these checks when the remote bitfield is mutated (onbitfield & onrange)? This will also ensure the value is updated when we have more info from the remote. Otherwise accessing _remoteContiguousLength directly will have less information than if calling .remoteContiguousLength. We also could explore replacing _remoteContiguousLength to be .remoteContiguousLength, though maybe should be a separate PR to keep scope simple and incremental.

Regarding that, could you add a test for a scenario where onbitfield updates _remoteContigousLength and later a broadcastRange() is called for the same peer but is skipped via the check here:

hypercore/lib/replicator.js

Line 650 in d53c83b

if (this._remoteContiguousLength >= start + length) return

[lejeunerenard]

Setting the fork isn't necessary as they both start at 0.