Community
Participate
Working Groups
M6 My installation history page is rather slow to come up (even though I only have 2 history) and it looks like if it is loading the profile registry in the UI thread. It is visible because my machine is slow.
Created attachment 134160 [details] Patch ProfileSnapshots now implements IDeferredWorkbenchAdapter, so the UI is not blocked anymore while the snapshots are retrieved In order to keep the behaviour consisting in selecting the first (most recent) snapshot in the viewer, I had to refactor the DeferredQueryContentProvider a bit...
Created attachment 134161 [details] mylyn/context/zip
CC'ing Susan, she may want to help reviewing the patch :) Since it's RC1, 2 committers need to give their +1: the one that will integrate the patch and another...
... reassignment magic as this is in the UI.
Hi, Benjamin. Thanks for the patch. I reviewed it, and it looks like the right solution to me, but wrong timing. I think it's too big for an RC1-level change. While the refactoring is minor, it means we're changing the content provider used in the other views. If we were simply changing the installation history code and not touching other working code paths, I might consider it. Unless someone can convince me that this is a critical performance issue for 3.5, I'm marking this 3.6 to do the right thing (Benjamin's refactoring) rather than hack some kind of surgical fix in for 3.5.
Comment on attachment 134160 [details] Patch I was premature in setting this flag, I didn't use the patch after all.
Fixed in HEAD >20090924. Thanks again for the patch, Benjamin. I updated it to the current code stream and refactored it a little, but ultimately decided I didn't like changing that top view to be a tree and relying on DeferredTreeContentManager (with all its quirks and bugs). I saw some odd blinkiness and once (only once) saw duplicate elements appear (well described in bug 226343) and then decided to try something simpler. I added some very basic deferred fetch support for table elements in the ProvElementContentProvider. Basically it uses IDeferredWorkbenchAdapter to determine if table elements should be retrieved in a job. With a table, you can do simple removes and adds to do the deferred fetch rather than rely on element collectors and the potential duplicates you get in bug 226343. I also did a barebones implementation of IDeferredWorkbenchAdapter in ProfileSnapshots, rather than move progress handling into the element building, because the time consuming part of the work is getting the timestamps from the profile registry, which doesn't take a progress monitor anyway. Added a test case that hammers the content provider to ensure no jobs are leaked or duplicated.
Verified on WinXP, Build id: I20091027-0100
