Feat/proxy performance #1247
Feat/proxy performance #1247
Conversation
…oped functions that return values faster It's much faster when repeatedly accessing variables, but we still need to investigate the memory implications when having a large number of component instances
|
Please don't merge this pull request yet. I'd like to do some further analysis on the performance of creating new component instances, memory usage and optimizer behavior. |
You mark it as WIP or move it to draft |
…ponent instance Because it does not impact proxy get performance and it does decrease memory consumption and improve instance creation performance.
… rather reuse them per component type Reusing ensures that memory usage is limited, while only slightly impacting performance.
… is created for every component instance
|
I changed some things in the original idea and did some extensive performance testing, comparing the current vue-next version with this PR. The results are further below, but most importantly they show that instance proxy performance in component instance creation has become about 15% slower (because some functions and function arguments need to be put into the propGetters cache), while setup access (particles test) has become about 75% faster. It only makes a slight impact on the total time, although in some cases (when there are many v-for items or components, and many setup accesses), there is certainly a performance improvement with this PR. In general, nothing beats exposing the setup state (as raw object) directly and changing the syntax to Nevertheless, I realise that we want to preserve the existing syntax. So for that case this PR can help limiting the performance difference somewhat. Still, I would prefer to see 'setup' and 'prop' being directly available, as mentioned by @RobbinBaauw in #1227. 100 new components per frame, 200 frames 100 reused components per frame, 200 frames Particles test (6000 updated v-for items within the same component, all requesting 1 setup ref): New flushJobs: |
|
Based on the data you provide, seems not worthy in the real world cases. |
|
First of all, thanks a lot of coming up with the idea and experimenting with this. Unfortunately, the gain here doesn't seem to justify the increased complexity of the implementation. I still think this is an area worth exploring - but I think a more compiler-informed approach would be more plausible. |
As mentioned in #1227, variable access from templates is a major hotspot in terms of performance. This PR reduces up to 80% of the variable access time. It does so by creating ultra-fast and optimizable getter functions.
The peformance difference can be seen here. Notice that the left side is with the changes in this PR, right side is the current Vue implementation. The 'get' time is much lower (70 vs 420) and overall it causes a performance improvement of about 10%.
In terms of memory usage, getter functions must be created per instance. Initial tests proved that it seems to has little effect on the memory usage.