Revert: Performance: Parallelize recursive directory copying (#2409) - #2520
Conversation
📊 Performance Test ResultsComparing da1097b vs trunk site-editor
site-startup
Results are median values from multiple test runs. Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change |
sejas
left a comment
There was a problem hiding this comment.
The revert works as expected. I was able to create and start new sites.
epeicher
left a comment
There was a problem hiding this comment.
Thanks @ivan-ottinger for working on a better option! I have tested creating multiple sites on both Mac and Windows, and I have not found any issues. On Windows, the performance of creating a site is still not good, but I have compared with trunk and this branch seems to be slightly better.LGTM! ![]()
| Sites created on Mac | Sites created onWindows |
|---|---|
![]() |
![]() |
This reverts the changes from PR #2409 which replaced the custom recursiveCopyDirectory function with fs-extra's copy. Brings back the sequential recursive copy implementation.
e077456 to
0ef05ee
Compare
Keep the fix from PR #2521 that always copies sqlite-command files on startup to ensure files are complete, but use recursiveCopyDirectory instead of fs.copy as part of the revert.
|
Thank you for your reviews, everyone! For completeness, the performance results of the original PR showed site creation slowdown despite my results in manual testing. This was a motivation to revert those changes in this PR. Interestingly, the performance results on this PR does not show any significant difference. The same is true when running the performance tests locally: Regardless, I will merge this PR to unblock Studio release and then continue working on #2502 which could speed site creation up. |


Summary
recursiveCopyDirectoryimplementationfs-extra'scopyin favor of the custom implementationThe copy logic will be revisited in #2502.
Related issues
Testing Instructions
npm install && npm start.