Re-ran the documented comparison end to end (11/11 scenarios valid, randomized
interleave, median of N, threads=8):
findrefs 6 queries 117-191 ms vs 830-1978 ms 7.1x - 11.5x
getclass early/late/miss 45/77/62 ms vs 124/259/245 ms 2.7x / 3.4x / 4.0x
manifest 13 ms vs 268 ms 20.3x
classes 98 ms vs 2318 ms 23.7x
geometric mean 8.0x
Up from 5.4-5.8x at the start of the session; getclass early, the only scenario that
used to lose (0.6x), is now 2.7x. Parity is unchanged: classes 567192/567192 and the
same handful of known reference-side row differences.
The rank-and-file fix: replacing the application-specific query during the privacy pass
left one scenario asking for a literal that does not occur in this archive (0/0 rows,
reported INVALID), and the scenario builder's first_class() helper called a function
that does not exist in this script. The scenario now uses a neutral literal with equal
row counts on both sides (okhttp, 126/126), and first_class() runs subprocess directly.
Found by an independent review and by differential testing against the
reference implementation (a reference, not ground truth):
- droidsaw-dex vendored with a class-scoped parse: getclass 0.6x -> 1.4x,
10-scenario geometric mean 5.8x -> 6.8x; 2070-class equivalence evidence
- DEX 041: getclass was completely broken (0x78-byte header), container memory
1.34 GB -> 3.4 MB, single-member naming, standard-header view for the
decompiler
- manifest: unknown value types no longer fail the whole document, resource-map
chunk validation, exact radix multiples instead of rounded ones
- ZIP: duplicate-entry handling, declared-size-driven allocations bounded
- scanner: per-class_def type-id resolution; no rasc-only rows in the ~770k
rows checked against the reference
Tsingshui