react-redux-benchmarks
react-redux-benchmarks copied to clipboard
reduxjs
Make existing benchmarks more realistic
The stockticker and twitter-lite benchmarks currently use an array for the root of the Redux state "tree", rather than an object with multiple slices. This is rather unrealistic. The tree-view example at least uses an object, although it's all just a single normalized lookup table rather than multiple slices too.
I'd really like it if these benchmarks were modified to separate the data into state slices. Using the stockticker benchmark as an example:
Right now, it's a single array of N entries, where N is defined in constants.js. I'd like to have a NUMBER_OF_SLICES constant that defines how many named state slices that should be split into. For example:
const NUMBER_OF_SLICES = 4;
const rootReducer = createRootReducer(NUMBER_OF_SLICES);
const exampleRootState = rootReducer(undefined, {type : "@@redux/init"});
console.log(exampleRootState);
// {slice1 : [], slice2 : [], slice3 : [], slice4 : [] }
With each of those slices having an equal number of items inside.
That way, the update patterns would be a bit more realistic - an update to state.slice2[123] would leave slices 1, 3, and 4 untouched.
This would require:
- Altering the reducer logic to dynamically generate slices during reducer setup
- Altering the root component(s) to do the same kind of work for each top-level slice (example: "render all stock ticker entries for
state.slice, then forstate.slice2", etc) - Passing down both a state slice name and an ID as props to the connected components so they know how to grab their own state if they're connected
Overall, I think this would give us some more realistic results.
What if modify redux dev tools, or create some middleware (or both), to let redux customers collect and send you a real information about how they are using redux? "Redux performance" could be a tab inside "redux dev tools".
- bad memoized mapStateToProps
- reselect statictics. Reselect visualization tool (like mobx one)
- "slices", how often they updated, and how they got consumed
- connect "explanation" - what does each "connected" component consume.
- built in component/selector benchmarks
@theKashey : it's an interesting idea, but it also sounds like a lot more work than we have time for (and also lots of complexities around gathering data, which I do not want to touch).
@taranvohra : thanks! Tell you what - fork the project, clone the repo, and start modifying the twitter-lite benchmark to use the approach I described. Once that's done, create a PR with the changes.
@markerikson My bad, I didn't notice and went ahead to refactor stockticker #10 because I was already reading on it . If that's okay I can get started with twitter-lite
Sure, that's fine. I left a request on the PR to switch how the actions are being dispatched - would appreciate it if you could tackle that first. After that, sure, go ahead and tackle the others.