Thread blocking with 100,000+ nodes. What does jotai do *after* retrieving an atom value?

[nganbread]

My application follows a tree like structure with over 100,000 nodes, where each node is an atom:

• A
  • B1
    • C1
    • C2
    • ...
    • C*
  • B2
    • C1
    • C2
    • ...
    • C*
  • ...
  • B*

^{(the tree is actually a couple levels deeper than this)}

Each C node can be marked as completed, and I need to display the completion % at levels A and B in real-time. To do this, I have a DerivedAtomB which calculates the completion stats for its C children. I then have a DerivedAtomA which performs the same, but on its DerivedAtomB children

The calculation of DerivedAtomA takes around 800ms and blocks the main thread, which is fine for me. However, after calculating the value of DerivedAtomA and returning it to the component, it takes an extra 2-3s for the main thread to be unblocked and the results of useAtomValue to be rendered. Furthermore, when I hide the component and then re-render it, the cached value is instantly returned, however the main thread still takes the same 2-3s to be freed again

My questions are;

• What is Jotai doing ("asynchronously") after returning the atom value from useAtomValue?
• Is there a way to mitigate this post-useAtomValue thread blocking?

---

Here's some sample code if it helps at all

  const aProgressAtom = atom<Progress>((get) => {
    const bProgress = get(a).bs.map((x) =>get(bProgressAtom(x))); // bs is a string[]. bProgressAtom is an atomFamily

    return {
      completed: bProgress.reduce((sum, { completed }) => sum + completed, 0),
      total: bProgress.reduce((sum, { total }) => sum + total, 0),
    };
  });

[dai-shi]

• What is Jotai doing ("asynchronously") after returning the atom value from useAtomValue?

Hm, Jotai does nothing async. Wonder if it's something with React.

• Is there a way to mitigate this post-useAtomValue thread blocking?

We need to understand what's happening. Can anyone help?

[nganbread]

Here is a minimal reproduction

https://codesandbox.io/s/jotai-demo-forked-q15l56?file=/src/App.js

The first time you click the button it

• Calculates the sum
• The UI becomes blocked
• Renders the result
• The UI becomes blocked

Once the UI has become unblocked, you can then hide the result and then show it again, which then

• Doesn't calculate the sum and retrieves the sum from the cache
• The UI becomes blocked
• Renders the result
• The UI becomes blocked

The "async" part seems to occur due to this useEffect, but it's still unclear why this is scheduling so much work when everything should be "cached'

[dai-shi]

Does commenting out L97 change the behavior?

[nganbread]

It definitely helps, but there's still a small latency when re-rendering, which is odd because everything should be "cached" at that point

Is L91 important? It doesn't seem necessary at it's triggering a render immediately after returning the component to React to be rendered. But I assume it's there for a reason?

[dai-shi]

jotai/src/react/useAtomValue.ts

Line 97 in fbfe21e

rerender()

is theoretically important for correctness in an edge case. useEffect is not guaranteed to fire immediately.

[nganbread]

When reading the atom value, jotai seems checks to see if any of the dependencies have changed. So while we don't read the value of all atoms, we still seem to touch them all.

Is it possible to avoid this check and just rely on write time "cache/atom invalidation"? (I've not looked very deeply into the source, so forgive me if this is a naive suggestion)

[dai-shi]

Removing it will make some basic tests to fail.
But, it's good point. It's costly. Wonder if we can add some condition to skip checking. 🤔

[dai-shi]

Can you try this?

diff --git a/src/vanilla/store.ts b/src/vanilla/store.ts
index 98eaf2db..73782ac0 100644
--- a/src/vanilla/store.ts
+++ b/src/vanilla/store.ts
@@ -324,7 +324,10 @@ export const createStore = () => {
       // Recursive calls to `readAtomState(a)` will recompute `a` if
       // it's out of date thus increment its revision number if it changes.
       atomState.d.forEach((_, a) => {
-        if (a !== atom && !mountedMap.has(a)) {
+        if (
+          a !== atom &&
+          (!mountedMap.has(a) || hasPromiseAtomValue(atomState))
+        ) {
           // Dependency is new or unmounted.
           // Recomputing doesn't touch unmounted atoms, so we need to recurse
           // into this dependency in case it needs to update.

[dai-shi]

oops, that doesn't add condition...
forget about it.
Hm, !mountedMap.has(a) means it will only check if not mounted, so it makes sense.

jotai seems checks to see if any of the dependencies have changed

Now, I wonder why it happens in your case.

[nganbread]

Ill have a deeper investigation when I find some time, hopefully in the next week or so

[dai-shi]

While working on #2016 and previously #1959, I would like to see if the alternative approach is possible, essentially as what you said:

Is it possible to avoid this check and just rely on write time "cache/atom invalidation"?

It will be a huge rewrite and some existing tests might fail. I'll try it anyway and see how it goes (or not).

[dai-shi]

My first attempt failed. Instead of a rewrite, I will try one by one.

[dai-shi]

Is it possible to avoid this check and just rely on write time "cache/atom invalidation"?

It turns out that that is not possible with the current design where we intentionally cache unmounted atom values in a WeakMap. This design won't change any time soon, because it's kind of the ground rule of the library.

#2029 is my refactoring, which is related to this discussion, but unfortunately it doesn't seem to fix the repro: https://codesandbox.io/s/jotai-demo-forked-q15l56?file=/src/App.js