Community
Participate
Working Groups
This bug report is based on support observation. Support very often has to deploy test plug-ins into dropins folder. Every new deploy causes Eclipse based start-up to take more time. Removing almost all .profile files reduces the start-up time from 20 minutes to 2 (90%!). This observation indicates that dropins reconciler reads all profiles. Can this be optimized?
original bug is reopened :-) *** This bug has been marked as a duplicate of bug 251561 ***
Actually I think this bug is interesting to remain open as a separate bug. The history might turn out to be the main cause of slowness everyone is seeing, but there may be other causes that would need addressing separately. I've added this bug as a dependency on bug 251561 instead.
I have tried to find out who reads profiles, but I havent got any significant results - debugger stops in Parser#parse only once during startup. I think I need a few hints to perform further investigation.
I would recommend looking at SimpleProfileRegistry around getProfileMap(). At some point in this code we go over all the profiles to find the latest one but we should not load them. Otherwise I would recommend using a Profiler to see where the actual time is going.
Update on inital bug report - it is necessary to remove *all* not *almost all* profile files.
Launching (relatively clean) RAD until workspace selection dialog appears: no changes in dropins: 3 seconds small changes in dropins: 90 seconds small changes in dropins + removed all profile files: 8 seconds. This raises several questions: 1. Is it safe to delete all profile files? Ok, I already know it is not. Is there any way to make P2 to recreate profiles? 2. Why everything works so fast without .profile?
> 1. Is it safe to delete all profile files? No. >Is there any way to make P2 to recreate profiles? No. >2. Why everything works so fast without .profile? Could you please do some profiling to find out?
btw, good findings!
I hate profiling, I prefer javacores. Ok, it appears that support also edits bundles.info to add there updated plug-in from dropins. Deleting .profile files simply disables P2. That is the whole truth. OSGI starts and loads bundles.info. That's the whole magic. During regular P2 startup a lot of javacores is taken in native methods: SiteListener.contains which refers to File. and: * Win32FileSystem.normalize * WinNTFileSystem.getLastModifiedTime I do not think we can get a lot of improvements here.
Yes, of course disabling p2 completely will be faster.
