Skip to content

3.2.5

Choose a tag to compare

@Pogut Pogut released this 03 Aug 16:35
· 17 commits to main since this release
6a3e501

RefactoringMiner Extension v3.2.5

A release focused on one theme: making the overlay's cost depend on how much of the diff is on screen, rather than on how many refactorings were detected. On a commit with 412 detected refactorings, INP went from around 1760ms to around 80ms.

Fixed: large commits made the page unusable

The extension did its work before you touched anything, and on a commit with a few hundred refactorings that work was enormous. Every repaint walked each line of every refactoring and searched the whole document for the matching diff cell, which on a page like that meant thousands of full-page searches. Those repaints were triggered by the diff itself, which mounts rows as you scroll, so the search ran again and again while you were trying to read the code.

Scrolling stuttered, clicking a refactoring in the panel took a noticeable moment to respond, and the highlights arrived late enough to look like they were flickering into place.

The matching now runs in the opposite direction:

  • The detected refactorings are compiled once into a lookup table of every line they touch, keyed by file, side, and line number.
  • Painting is a single pass over the diff cells currently on screen, each checked against that table. Nothing searches the document per refactoring any more.
  • Resolved cells are remembered, and re-checked against what the cell is actually showing before they are reused. The Preview diff recycles its rows as you scroll, so a cell that is still on the page may have quietly become a different line.

On the 412 refactoring commit this took INP from around 1760ms to around 80ms. A synthetic stress test of 3000 diff rows carrying 1000 refactorings, well past anything seen in practice, brought a single paint from around 520ms down to around 5ms, so the page stays responsive well beyond the sizes that used to break it.

Old INP

old

New INP

new

Fixed: highlights appeared late while scrolling

Newly mounted lines waited out a 250ms delay before they were highlighted, which on a fast scroll read as highlights blinking in behind you. That delay existed because repainting used to be expensive enough that it could not be run often.

Now that a repaint is a single cheap pass, it runs once per frame instead. Lines light up as they arrive, and rows that the diff recycles into something else are cleared just as promptly.

Selecting a refactoring is now immediate

Clicking a row in the refactorings panel, stepping with the navigator, or clicking a minimap tick jumps to the line and blinks it without the pause that used to precede it. The unfolding of hidden lines from v3.2.3 still happens first when it is needed, and it is still the only thing you wait on.

The blink itself is unchanged. Same three attention flashes, same synced pulse afterwards, same speed and colour preferences. Only the work underneath it got cheaper: the pulse now toggles a known set of cells instead of re-searching the page on every tick, which is what used to make it stutter mid-scroll.

Nothing else changed

This release is entirely internal. Tagging, selection, revealing folded context and collapsed files, the hover peek, the minimap, the navigator, the edge chips, and the refactorings panel all behave exactly as they did in v3.2.3, and were verified to tag the same cells with the same data. The permission footprint is unchanged from v3.2.1.

Reload the extension, not just the page, to pick up this build.

Fixes #25.