f16175 *** STAGE 7 ***
f17129 Segment 0: 954
f17945 Segment 1: 816 (T4:814) Miniboss Skip set-up
f18487 Segment 2: 542 (T4:501) Miniboss Skip set-up
f18675 Segment 3: 188 (T4:106) Miniboss Skip set-up
f18744 Segment 4:_ 69 (T4:236; T7:69) Miniboss Skip
f18952 Segment 5: 208 (T4:206) Lagged
f19344 Segment 6: 392 (T4:407) Positioning after miniboss
f19968 Segment 7: 624
f20158 Segment 8: 190
f20513 Segment 9: 355 (T4:356) Changed block destrction
f20867 Segment10: 354
f22279 Segment11:1412 (T4:1411) Frame rules?
=== END OF STAGE 7 (Frames: 6104) === (T4:6159)
We still have +2 lag following the miniboss, but I did get rid of one lag frame and managed to pull together some ammo without lagging somehow. Also fixed the boss, which did apparently require minor edits to have it work, so not a complete resync.
I blame the array starting at IWRAM:7C44, and object data offsets +0x0E (2 byte) and +0x40 (4 byte), for being a malloc substitute for painting sprite graphics. Due to the fact I destroyed a different enemy for my ammo, this somehow caused 2 lag frames later, which was removed by attacking a lag bomb to delay its self-destruct, and to delay a charge so I omit its graphics for just a little longer and avoid the second lag frame. Nice to see removable lag.
Again, I blame some graphics allocation routine involving those object offsets and the array. Probably scans through from the start of the array and works forward trying to find a large enough open region. And the regions are distributed differently from different enemy destruction, probably extending the search and lagging as a result. Or so I suspect.