Re: [whatwg/dom] Atomic move operation for element reparenting & reordering (Issue #1255)

The benchmark discussion was simply us assessing whether it's fast enough for it to be viable for us to use - if it's too slow, the throwing variant is outright useless to us. And switching to a method that moves instead of removing and inserting would allow us to fix a longstanding animations bug: https://github.com/MithrilJS/mithril.js/issues/2612.

It's incredibly important to me that it meets my performance requirements. And those requirements are stiff: around 5 µs/op firm and 50 µs/op hard. (Soft affords ~1k keyed element moves without dropping frames at 60 FPS, and hard affords ~100 moves.) Slower than that, I simply can't switch to it.

> By the way, keyed moves have the strictest deadlines for this. Other callers can tolerate as much as 100x slower for `insertBefore`.

A `try`/`catch` can add as much as 0.5 µs/op, and I *believe* the `insertBefore` currently clocks in at around 1-3 µs/call on my laptop. This overhead is *not* negligible. If falling back is needed, elements that don't support moves would likely clock in around 2-5 µs/call if performance turns out to be similar between the two. This means we'd be able to tolerate a dynamic fallback, but only barely.

This is why I'm so concerned and pushy about it. We need the ability to just move, and we need simple node movement to be very fast.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1255#issuecomment-2498934898
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1255/2498934898@github.com>