Introduce {type: 'last', number: 1} memoize interface

[zhujinxuan]

Do you want to request a feature or report a bug?

feature

What's the current behavior?

For all memoized functions, we cache all evaluated result. That may result cache miss and memory leak.

What's the expected behavior?

For several functions, we shall only cache the last result.

1. Functions not used by slate. Like getBlocksByType
2. Functions recieve immutable Object. Like getBlocksAtRange. It is not easy to re-hit the same cache with the same immutable Object after several operations.
3. normalize. When normalize node is non-null, it will be normalized and the node is stored in history stack. We do not need to cache this function unless user has a lot of undo. (Additionally, current undo->redo conflicts with normalization, when an undo triggers a normalization, then the redo stack is overwritten.)
4. atOffset, atPosition. These functions are always called with the current selection. If selection are changed, it will be unlikely to be called again. Perhaps we can only cache the last one or last three result of this function.

Just wondering if there is anyone else working on memoize interface. I can work on this in Oct if there is none else working on it.

[ianstormtaylor]

Interesting ideas @zhujinxuan!

For 2, it might be interesting to design a way for Immutable.is to be used for comparisons? Although I'm not sure if that would slow things down too much for the case where the object is actually different.

For 3 that's a great point. We can ignore the "lots of undo" case too, not caching that method at all sounds good to me.

I'd like to get rid of the *AtPosition methods if possible, and replace them with *AtPoint methods instead, to stay more consistent with the rest of the codebase. This might also be helped by using Immutable.is for comparisons, since it will be harder to memoize otherwise.

---

All that said, I think there is potentially more important work to be done for performance in converting many of these *AtRange methods to use paths instead of keys, which might even make them fast enough to not need memoization at all, which would be really good for memory usage. Specifically I'm think about the issues from:

• convert remaining Node.get* methods to use paths #2000
• get*AtRange could be short-circuited to improve performance #679
• make mapRanges usage smarter #2003
• expose path to schema normalize functions #2002
• convert AfterPlugin to use paths #2022

I think the gains from using paths on these might be really big. I'd rather merge fixes there before adding more complexity to our memoization techniques, or adding more complexity with performance hacks elsewhere.

[zhujinxuan]

If we want to use Immutable.is to compare. We have to limit the potential candidates to compare for performance. I think perhaps caching the last one or last three is a solution.

[ianstormtaylor]

As of #3093 (which was just merged), I believe this issue is no longer applicable, because a lot has changed. I'm going through and closing out any potential issues that are not out of date with the overhaul. Thanks for understanding.