[jonasbernardo]

Opening a box reads every frame of the file and verifies the CRC of the whole frame, value included, even for a LazyBox (BinaryReaderImpl.readFrame checks it before deciding to keep only the key). In our app, opening a 59 MB lazy box with 1,518 keys was the biggest wait between the splash screen and the first content. Three changes make it about twice as fast, without touching the file format:

• Crc32.compute uses slicing-by-8. Eight 256-entry Uint32List tables (8 KB, built once) let the loop consume eight bytes per iteration instead of one. The result is bit-identical to the old byte-at-a-time table.
• BufferedFileReader.loadBytes copies the leftover bytes with setRange instead of a byte-by-byte loop.
• FrameIoHelper.keysFromFile reads boxes bigger than 1 MiB in 1 MiB chunks instead of 64 KB ones. Boxes up to 1 MiB keep the default chunk.

Measurements

Android, Infinix X6837 (8 GB RAM), profile (AOT) build. openLazyBox on a cold process, in a background isolate, crashRecovery: false. One APK containing all four variants, the variant picked per launch; alternating order (ABCD/DCBA); 2 rounds × 10 launches per variant. Every paired launch was faster than the original.

Box	Original	CRC only	Copy + chunk only	All three
59 MB, 1,518 keys	1,455 ms	1,154 ms (−21%)	965 ms (−34%)	716–733 ms (−50%)
6 MB, 360 keys	182 ms	143–158 ms	111 ms	71–81 ms (−56 to −61%)

On an M4 Pro Mac (AOT executable), the same 59 MB box opened in ~218 ms before and ~51 ms after (−77%); there the CRC alone accounted for most of it.

Correctness

• New unit tests compare Crc32.compute with a bitwise reference (no tables) for every offset 0–15 × length 0–300 × six initial CRCs, unaligned views, a 1 MiB buffer and chained calls. They run on the VM, dart2js and dart2wasm.
• A new integration test reopens normal and lazy boxes whose frames (up to ~150 KB) straddle the read chunks.
• Each change was checked by breaking it: swapping two tables, a wrong shift, a wrong setRange offset and disabling the big-box branch all make the new tests fail.
• Outside the repo, on the real 59 MB box: on the device, the new CRC matches the old one and the stored CRC of all 1,649 frames, the whole-file CRC matches zlib.crc32, and 20,000 random slices with random initial CRCs and unaligned views match. On the Mac, recovery of 7 damaged copies (truncated mid-frame, flipped bytes) ends at the same size with the same keys, and files written by either version are byte-identical and readable by the other.

🤖 Generated with Claude Code

[Rexios80]

This PR touches internals I am not very familiar with. It will take a while to validate.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.89%. Comparing base (6dfa776) to head (7f7d9e6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #357      +/-   ##
==========================================
+ Coverage   93.78%   93.89%   +0.11%     
==========================================
  Files          66       66              
  Lines        2685     2734      +49     
==========================================
+ Hits         2518     2567      +49     
  Misses        167      167              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Rexios80]

Thank you for the contribution! This made me curious what other optimizations could be made, and now IsolatedHive is also waaay faster. Even faster than normal Hive in some cases. This is released as v2.23.0.

[jonasbernardo]

I'm happy to be able to contribute; I've always had this problem with slow opening times. Compared to other solutions, AI helped solve