jasonphillips

I rebased and also added a better test to `slate-react` for decorations, which uses nested blocks so that performance issues show up: https://github.com/ianstormtaylor/slate/pull/4997/commits/63c277c916375bc6f0350c198df14bc6e6784446 We should have 6 `decorate()` calls for...

Maybe there's a way to get the best of both approaches... caching decorate as suggested, but instead of caching it per-leaf we'd need it to be cached per entire render...

One more problem with the leaf-based logic that I realized when testing a bit: if we were to only redecorate from the leaf level (meaning _when the leaf rerenders_, calls...

> Perhaps this is due to our logic calculating decorations in a denounced manner? We wait for about 30ms of no input change before we update our decorations -- which...

> We debounce with a setTimeout based on the serialized value of the editor -- and then yeah, we recalculate all our decorations and update the top-level decorate function such...

> We debounce with a setTimeout based on the serialized value of the editor -- and then yeah, we recalculate all our decorations and update the top-level decorate function such...

@MattIPv4 Just thinking of possible causes... Could there be any place in your code where you mutate decoration objects instead of using them immutably? A performance improvement in this PR...

Jumping in on this for a moment since I was tempted to implement this same optimization today, then found this PR. > More importantly, this optimization doesn't work when max_new_tokens...

@dfyz Excellent find! I was searching for a discussion like that one in their repo. It seems to me that Option 3 is probably not desirable, as you already noted....

@dfyz I may not have written very clearly—I meant that when the cut happens, we would drop the cached keys/values and intentionally recalculate everything from scratch (for the newly cut...