Closed leeoniya closed 1 year ago
Don't think that there will be any noticeable perf difference. I think that I've switched to entries in this benchmark when I've experimented with dynamic lists for immutable collections that doesn't generate key arrays and used prev entries to retrieve previous keys. This experiment was a mistake.
I'll update pull request and change it back.
i'm curious how the benchmark performs with your fixed SCu? 🤔 i was a bit worried things might regress a lot once that was removed from the impl, so actually glad to hear it wasnt working anyways 😅
i'm curious how the benchmark performs with your fixed SCu?
Without sCU:
Vanilla / With sCU:
if that's the most significant difference then yeah, simpler implementation FTW :+1:
i hate these massive 16x CPU slowdowns, almost as much as i hate that the benchmark is dominated by layout/reflow in many cases.
hey @localvoid
wondering why you switched to using Entry directly for
selected
rather thanentry.id
? except, oddly, ingetKey(entry) => entry.id
.is there a perf win to not using id? i actually prefer the
id
version since it demonstrates the vdom lib does not expect referential integrity from row items (you can JSON.parse() a new set of entries without breakage), which is a big advantage that some fine-grained libs dont have. using id feels more "nothing up my sleeve" honest.