You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 24, 2020. It is now read-only.
Currently, we don't have any sort of benchmarks or timing data to validate the performance of this library. It's native and should be really fast - but it'd be helpful to have concrete data on how fast, what the limits are, etc.
Proposal:
We add some simple benchmarks around reconciliation. For example, some deeply nested tree of components where we repeatedly call reconcile. It would be helpful to profile both the timing and memory profile (allocations).
We should simulate cases where appendChild is very fast
We should simulate cases where appendChild is slow (ie, a thread sleep)
We add an automated test case that validates the performance - so we know if a change regresses performance. This timing data would be machine-dependent but if we keep benchmarks per CI environment, perhaps that would be enough to examine performance build-over-build. (this would helpful to have in general for the reason ecosystem!)
Currently, we don't have any sort of benchmarks or timing data to validate the performance of this library. It's native and should be really fast - but it'd be helpful to have concrete data on how fast, what the limits are, etc.
Proposal:
reconcile
. It would be helpful to profile both the timing and memory profile (allocations).appendChild
is very fastappendChild
is slow (ie, a thread sleep)An excellent example of helpful benchmarking is the work @jordwalke did in his
flex
library: https://github.com/jordwalke/flex#benchmarkingThe text was updated successfully, but these errors were encountered: