3 ms·

as absurd as it may seem to you, this is a react feature. the upcoming react 18 release is pretty much based on concurrency. this is the test you are referring

as absurd as it may seem to you, this is a react feature. the upcoming react 18 release is pretty much based on concurrency. this is the test you are referring to: https://docs.pmnd.rs/react-three-fiber/advanced/scaling-performance#enable-concurrency https://docs.pmnd.rs/react-three-fiber/advanced/scaling-perf... the github repo now contains a vanilla test that you can run

Jasper_ 5y ago
As I said, "schedule" just means "defer work to future frames". That's a valid strategy if you have severe load, but it's not globally applicable: one might imagine that two components need to be updated together (e.g. updating the arms and body of a character should not be split up between two frames, or else the user will see split bodies for in-between frames). At the very best, this sort of scheduling should be informed by gameplay systems. It can "effortlessly outperform" only if we're talking about throughput, not latency here -- the scheduler ensures that less is done each frame so we can meet 60fps each frame, at the expense of having things done frames later than when they probably should have been. I'm aware this is all a React feature. I disagree with the React team that "concurrency" is a usable solution to performance in all cases. But I can respectfully disagree with them about that. I can understand why a scheduler helps improve user-perceived performance. I'm happy to talk about what I believe are the tradeoffs. Regardless of all of that, updating 2,000 cubes should never cause 700ms of load to begin with. The test you linked me to is not the same test. The test in the tweet is seen here [0], and has no artificial runtime delay as far as I can tell. For extra irony, note that they already have to bypass React (which is described as ItemSlow), in favor of the "Zustand approach", aka modifying things imperatively. Remember, Three.JS is already running every frame, and rendering every frame, with or without a scheduler. That means that the 700ms overhead has to be coming from the React / R3F part of the demo. [0] https://github.com/pmndrs/react-three-fiber/blob/e3a71baad421a8b431866483d7d519e90c604206/examples/demos/dev/Benchmark.js https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42...
- mlsarecmg 5y ago
  what you link there has more to do with react vs zustand. if it interests you, read up on react 18 concurrency, this is the bit you are missing in this discussion.
  - Jasper_ 5y ago
    No; that's not the test in question. The tweet I started the conversation with [0] shows a bunch of cubes, not text geometry. It's not the text geometry test. It's just creating and manipulating a bunch of cubes. Unfortunately, it was removed from the react-three-fiber examples, so it can't be easily run unless you check out an old version of the repo. It contains two switches, one for React vs. Zustand, and the other for Concurrency On vs. Off [1]. The tweet is talking about the concurrency mode. I'm very familiar with React 18 concurrency, and gave my detailed analysis of it. The documentation you linked even confirms my analysis of it deferring work across frames: > it can potentially defer load and heavy tasks I've already given my feedback about that approach. I heavily suspect the overhead here is all React's reconciler / differ, as Svelte, which has no scheduler, performs similarly to the concurrent React mode[2]. [0] https://twitter.com/0xca0a/status/1199997552466288641 https://twitter.com/0xca0a/status/1199997552466288641 [1] See the description in the panel here. It's talking about React 18 concurrency. https://github.com/pmndrs/react-three-fiber/blob/e3a71baad421a8b431866483d7d519e90c604206/examples/demos/dev/Benchmark.js#L123-L147 https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42... [2] https://twitter.com/Rich_Harris/status/1200805237948325888 https://twitter.com/Rich_Harris/status/1200805237948325888
    - mlsarecmg 5y ago
      i've written them. the first pits react against zustand, it naively lets react churn through the whole graph 60 times per sec, you wouldn't do that ever, but zustand could. i initially tweeted it for people interested in that lib. some got it in the wrong throat, so i changed the test to actually pit it against a vanilla counterpart, and they were silent. the real test, contest that please, let the zustand thing go.
      - Jasper_ 5y ago

Jasper_ 5y ago

As I said, "schedule" just means "defer work to future frames". That's a valid strategy if you have severe load, but it's not globally applicable: one might imagine that two components need to be updated together (e.g. updating the arms and body of a character should not be split up between two frames, or else the user will see split bodies for in-between frames). At the very best, this sort of scheduling should be informed by gameplay systems. It can "effortlessly outperform" only if we're talking about throughput, not latency here -- the scheduler ensures that less is done each frame so we can meet 60fps each frame, at the expense of having things done frames later than when they probably should have been. I'm aware this is all a React feature. I disagree with the React team that "concurrency" is a usable solution to performance in all cases. But I can respectfully disagree with them about that. I can understand why a scheduler helps improve user-perceived performance. I'm happy to talk about what I believe are the tradeoffs. Regardless of all of that, updating 2,000 cubes should never cause 700ms of load to begin with. The test you linked me to is not the same test. The test in the tweet is seen here [0], and has no artificial runtime delay as far as I can tell. For extra irony, note that they already have to bypass React (which is described as ItemSlow), in favor of the "Zustand approach", aka modifying things imperatively. Remember, Three.JS is already running every frame, and rendering every frame, with or without a scheduler. That means that the 700ms overhead has to be coming from the React / R3F part of the demo. [0] https://github.com/pmndrs/react-three-fiber/blob/e3a71baad421a8b431866483d7d519e90c604206/examples/demos/dev/Benchmark.js https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42...

mlsarecmg 5y ago
what you link there has more to do with react vs zustand. if it interests you, read up on react 18 concurrency, this is the bit you are missing in this discussion.
- Jasper_ 5y ago
  No; that's not the test in question. The tweet I started the conversation with [0] shows a bunch of cubes, not text geometry. It's not the text geometry test. It's just creating and manipulating a bunch of cubes. Unfortunately, it was removed from the react-three-fiber examples, so it can't be easily run unless you check out an old version of the repo. It contains two switches, one for React vs. Zustand, and the other for Concurrency On vs. Off [1]. The tweet is talking about the concurrency mode. I'm very familiar with React 18 concurrency, and gave my detailed analysis of it. The documentation you linked even confirms my analysis of it deferring work across frames: > it can potentially defer load and heavy tasks I've already given my feedback about that approach. I heavily suspect the overhead here is all React's reconciler / differ, as Svelte, which has no scheduler, performs similarly to the concurrent React mode[2]. [0] https://twitter.com/0xca0a/status/1199997552466288641 https://twitter.com/0xca0a/status/1199997552466288641 [1] See the description in the panel here. It's talking about React 18 concurrency. https://github.com/pmndrs/react-three-fiber/blob/e3a71baad421a8b431866483d7d519e90c604206/examples/demos/dev/Benchmark.js#L123-L147 https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42... [2] https://twitter.com/Rich_Harris/status/1200805237948325888 https://twitter.com/Rich_Harris/status/1200805237948325888
  - mlsarecmg 5y ago
    i've written them. the first pits react against zustand, it naively lets react churn through the whole graph 60 times per sec, you wouldn't do that ever, but zustand could. i initially tweeted it for people interested in that lib. some got it in the wrong throat, so i changed the test to actually pit it against a vanilla counterpart, and they were silent. the real test, contest that please, let the zustand thing go.
    - Jasper_ 5y ago