Community
Participate
Working Groups
Hello, below are the points I noticed while analyzing the last Yourkit snapshots I took against a stand alone Eclipse starting on a 120 projects workspace. Please note that, as I open a RAD workspace with Eclipse, hence missing the appropriate builders and thus having a lot of errors / warnings. This might explain why the MarkerView classes / methods are flagged by Yourkit. I'm not saying that MarkerView causes perf issues in the startup process: it's just that it appears in Yourkit Hot Spots. I wonder if we could gain perfs is some methods, though assuming this has already been investigated... Memory Hot Spot by object count #2: org.eclipse.core.internal.resources.MarkerReader_3.readMarkerInfo(DataInputStream, List) #3: org.eclipse.core.internal.resources.MarkerReader_3.readAttributes(DataInputStream) Hot Spot by object size #3: org.eclipse.jdt.internal.core.index.DiskIndex.readStreamChars(FileInputStream) #4: org.eclipse.core.internal.resources.MarkerReader_3.readAttributes(DataInputStream) Method list: #2 for the size: org.eclipse.core.internal.resources.MarkerReader_3.readAttributes(DataInputStream) CPU Hot Spots 8 out of 10 Hot Spots are linked to the MarkerView (Problems view): save / restore the markers sort / compare data tree Filtered list in the to_be_attached screen shot.
Created attachment 61991 [details] screen shot
The memory hot spots from MarkerReader don't surprise me. It looks like this workspace has 25,000 markers, each marker has a number of attributes, etc. The CPU hotspots in MarkerReader and MarkerManager#restore... also look reasonable to me. The hotspots in MarkerWriter and MarkerManager#save look strange. These methods are only called on a full workspace save, which AFAIK only happens during shutdown. Does this trace include both a startup and a shutdown?
(In reply to comment #2) John, no, I don't think my snapshot included a shutdown, as I mainly focused on startup. Anyway, did you consider a snapshot could be causing the save action?
I considered the snapshot case, but the code paths look different. On full workspace save, MarkerManager#save is called. On workspace snapshot, MarkerManager#snap is called instead. I'm fairly sure a full workspace save is included in this snapshot. You can double-check a save is occuring by adding these options flags: org.eclipse.core.resources/debug=true org.eclipse.core.resources/save=true
(In reply to comment #4) John, I had another go and took new CPU / Memory snapshot, and had the same results as the above. I think the problem here is that I'm focused on the startup performance, and may be I was not clear enough about the way I collected these snapshot. In order to collect info as soon as the workbench is launched, here is how I did: - start Eclipse - check-out the org.eclipse.core.runtime plug-in, and performed some modification in order to trigger the Yourkit agent in InternalPlatform constructor. - create a launch config that activates Yourkit agent and targets my 110+ projects workspace - launch this config - once launched config is usable (after the Java Initialization job), start the Yourkit UI, connect to the active agent znd take my snapshots. So, I confirm, the referenced snapshot was taken only at startup (no shutdown).
I missed a code path when I looked at this before. MarkerManager.save is also called when a project is closed (IProject#close). Hoever, this also doesn't happen on startup as far as I know.
(In reply to comment #6) After a second look at the screen shots taken on 03/28th, it sounds like the MarkerManager.save method is never called at startup (which demonstrates that I obviously performed a shutdown while taking the first snapshot - sorry for that) I'll attach 2 other screen shots - new CPU and MEM snapshots.
Created attachment 63340 [details] new CPU snapshot
Created attachment 63341 [details] new MEM snapshot
I have just done a similar test with XRay and build I20070410-1043 If you load all of platform-ui and then restart 14.5% of your time will be spent in SaveManager#restore - the problems view didn't even show up in my trace (I have marker limits set to the default 100). Moving to runtime - I will attach the trace
Created attachment 63663 [details] Screenshot of trace
So...? Is there a problem here? SaveManager#restore loads the entire workspace space from disk. I would expect this to take plenty of time on a non-trivial workspace.
Closing.
(In reply to comment #12) John, we're not saying there is a problem here, this bug was opened just to investigate if some methods could be improved in order to gain some performance on the startup scenario. If we could gain 5 % on the SaveManager#restore... Improving the marker view overall performance would benefit the ide, and all eclipse based products. We already opened jdt.core bugs in a same way and found safe improvments (see bug 171653 for an example).
(In reply to comment #10) Tod, may be we should alter the summary to "SaveManager#restore takes too much time at start-up" or "Improve SaveManager#restore performance at startup"? time compared to the size of the workspace - and / or the number of errors / warnings in the wks. (I encountered the same behavior as the one you described, with the markers not showing-up in the markers view)
Thanks for the useful profile data, but there isn't anything valuable in this bug so I am going to close yet. I have spent lots of time in previous releases optimizing startup, and this bug doesn't shed any new light that could help further optimization.
