5.6.17

Performance regression fix (vs v5.6.11–v5.6.16)

gextract calls touching many dense tracks (e.g. ~50 motif tracks) became 10–20× slower starting in v5.6.11. Two compounding causes:

• MmapFile used MAP_POPULATE, eagerly paging in every mapped track at every chromosome transition (already covered by MADV_SEQUENTIAL).
• The two track-validation loops in create_expr_iterator and TrackExpressionVars::init were calling GenomeTrackFixedBin::init_read() once per chromosome per track on every gextract call, paying open + mmap + madvise + close + munmap each time even though they only needed bin size and file size. Replaced with a metadata-only path that stat()s for size and reads bin_size only once per track.

Net effect on a realistic workload (51 LSE motif vtracks × 7000 tiles × 5 chroms): 22s → 0.4s (~55× speedup, also faster than pre-audit baseline).

Added an opt-in performance regression test (MISHA_PERF_TESTS=true R -e "devtools::test(filter='perf-regression')") gated out of the parallel test suite.