PDE startup is slow because much of the initialization work happens on the main thread, blocking the application from becoming responsive.
PR #1300 explored moving several initialization tasks to background threads and demonstrated that this can significantly improve startup performance. The PR was ultimately closed in favor of revisiting startup concurrency with a more centralized approach, rather than introducing multiple ad-hoc threads in startup code.
Relevant quotes:
@tychedelia: “Have you considered using an ExecutorService instead of manually creating all the threads? That could provide better control or allow thread reuse particularly for tasks that are small.”
@catilac: “If there is a thread pool manager we can use to manage threads we should use that. I'd prefer we not introduce the use of low-level concurrency primitives on the app startup code paths.”
I'm opening this issue to capture these insights, so startup performance work can be revisited later.
PDE startup is slow because much of the initialization work happens on the main thread, blocking the application from becoming responsive.
PR #1300 explored moving several initialization tasks to background threads and demonstrated that this can significantly improve startup performance. The PR was ultimately closed in favor of revisiting startup concurrency with a more centralized approach, rather than introducing multiple ad-hoc threads in startup code.
Relevant quotes:
I'm opening this issue to capture these insights, so startup performance work can be revisited later.