Open kacper-mikolajczak opened 2 weeks ago
Current assignee @mountiny is eligible for the AutoAssignerNewDotQuality assigner, not assigning anyone new.
Additionally, the performance of getPathFromState
was checked and it takes about couple of ms to calculate as well:
Before
https://github.com/user-attachments/assets/9d52007f-7502-4c55-b258-485eb4e6473c
After caching normalized configs calculation (via createNormalizedConfigs
method) reduces this time to under 1 ms:
After
https://github.com/user-attachments/assets/9a440630-818d-4629-a2c6-3c83db6ff2d7
Problem
When
getStateFromPath
receives big linking config (example) as an option parameter, it tends to slow down quite drastically.Investigations
The config-related data is created every time
getStateFromPath
is called, resulting in noticeable overhead.Often times, configs provided to
getStateFromPath
are going to be static (e.g. initialised once at the app setup and remained untouched throughout its lifetime) and the data derived from it could also be static.Solution
PR tries to improve
getStateFromPath
helper performance by extracting and caching latest calculations related to linking config. We will only keep the latest value due to static nature of the linking config - it looks like a ok heuristic :)Results
Testing was done on iOS iPhone15 simulator by instrumentalizing
getStateFromPath
module as follows:After applying caching, the execution time of
getStateFromPath
dropped from 15-25ms to under 1ms for subsequent calls after the first one.Before
https://github.com/user-attachments/assets/3876e1ff-f91c-45dd-9d7b-f2ff0249b512
After
https://github.com/user-attachments/assets/4c6148fc-3baa-404a-a3be-b0666523fc09