Performance enhancements in niche situations

[dakom]

I hit on a couple things that were a bit surprising to me... not sure what I'm really asking here, other than if these things are documented somewhere. Also kinda just going with the flow where this seems to be the place to raise generic "issues" even if they're not bugs :)

1. keys can make things slower

I had a bunch of items, and the only thing that changed was their x/y positions. adding a key with index made rendering slower. It's possible this is short-sighted though since it could very well change once that "layer" has more items changing above/below it, but I found it interesting.

2. rendering null makes a huge difference

I had two test cases - a full graphics pipeline vs. an essentially empty POJO renderer. The difference in speed didn't matter about the data or graphics, but rather about what was returned in the components render(). For DOM this doesn't work of course - but for custom renderers, when it's known that a certain type of element will be an edge node - doing the side effects in render() (or some other lifecycle) and then returning null is significantly faster than even a straight functional component that returns a simple element (which does the same side effects). This makes sense, since react then has less branches to consider (even if those branches point to nothing other than simple objects).

[gaearon]

It's hard to say anything without seeing specific cases and how you measured them. :-)

[dakom]

Here's a work-in-progress repo: https://github.com/dakom/react-renderer-test (see live demo) - just pick a strategy and click to add bunnies

I'm hoping to add more test cases and it's more of a live-tinkering thing than a proper benchmark, but I think playing around with it you can get the feel. Sorry it's not more organized right now :\

If there's anything I can do to make it easier to discuss please let me know.

The interesting bits are mostly in https://github.com/dakom/react-renderer-test/tree/master/src/app/game/io/renderers/ (though I moved the custom-pixi renderer into its own repo for now- linked below)

Specifically, the Empty renderer, which doesn't really push anything, just placeholder objects, feels very similar in performance to either the PIXI-DOM renderer or the PIXI-Custom renderer depending on whether or not it's rendering out null edges. You can toggle that in the Empty View here - though right now there's no easy way to do that via the live demo.

What I feel from the live demo is that screen-drawing and extra computation from PIXI isn't really changing much once you get to a certain number of bunnies. It seems to me that the difference of whether or not it's rendering null edges seems to be the biggest performance factor by far, rather than using one renderer vs. another, and using keys also makes a difference there.

Hope that helps!

[dakom]

I've now updated the demo with two separate cases: Empty-Null and Empty-Edges

They both use the same source with the only difference being that at the edges (per-"bunny"), one version renders a proper element while the other renders null

I also updated the description on the demo to explain the results and test cases. I think it's much clearer now :)

I'm also a little confused about how rendering "null" fits into the tree... I see it doesn't call appendChild via the renderer, but it is added to the children props of the parent component.

Once I understand that a bit better - my goal would be, I think, to have special elements that are definitively not containers and can therefore somehow see the same performance gains as though they had rendered null, if that makes sense.

It's sukkot in Israel soon so I'll probably be afk more than usual, very happy to followup on this later. Thanks for taking a look!

[gaearon]

I'm a bit busy with other things too but I'll try to look at it some time next week. If I forget please ping.

[dakom]

I also forgot about this since now I'm focused on actually using the renderer ;) but if you're still interested, here's your ping :)