nodeReducer optimization about sigma.js HOT 3 CLOSED

1. Good point. I actually just realized that the first thing I do in most my reducers is cloning... I will document this in the new v3's doc.
2. Interesting - are you sure it's faster on all most used browsers? If we're sure it's always faster, we can update it.

from sigma.js.

Sweet! re: #2, I am pretty sure it's faster in most cases (it seems like in general just avoiding the overhead of a function call is pretty performant), but tbh I'm seeing some conflicting info about exactly how much of a performance improvement it is in a real world scenario.

It sounds like node/some browsers do a lot of aggressive caching with the spread operator which might impact the results of something like a jsperf test in an unrealistic way.

Anyways, I suspect it would make things faster but don't feel quite informed enough to push super hard either way! For v3 you could even provide an option while creating the reducer to skip cloning if people don't want/need it.

But either way I'm happy with it how it all worked out for me and will leave you all to decide what works best for Sigma, thanks again for all the great work here : )

from sigma.js.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from sigma.js.