Community
Participate
Working Groups
Opened in response to https://bugs.eclipse.org/bugs/show_bug.cgi?id=122720 for Igor. I suggest to add Visitor-style API for IVirtualComponent and/or IVirtualFolder traversal. Users of this new API would be able to choose depth of virtual tree traversal (should workspace resources be traversed? should dependent components be traversed too?). This should give enough flexibility to the clients to limit traversal to only necessary resources thus greately improving overall performance. Also, by separating traversal from actions done on resources, it should be possible to avoid multiple scan/correlate passes as described in item 4 and probably 2 as well. I also expect that VirtualContainer#members can be reimplemented more efficiently using this proposed API, so there will be just one traversal code used by all VirtualComponent users. This API should solve bug 103888 too. To give you some numbers, it takes ~800-900 milliseconds to process ResourceChangeEvent with current implementation in workspace (which feels very luggish, almost disturbing). The same ResourceChangeEvent is processed in <50 mills when reimplemented using proposed API. I would really want to hear from WTP developers. Does this sound reasonable? Do you think this API will improve WTP scalability? Are you going to accept patches given they are of a good quality (keep in mind though that this seems like a lot of work, which I want to do only if you are more likely to accept the patches).
I'll leave this untargetted until we have more information and some patchs.
I have to admit that my original patch was not that good and it took me much more time than I expected to come up with something I think worth looking. The new patch does not introduce visitor-style API per-se, but instead it provides new *lazy* implementation of virtual tree. This new implementation is slightly lower-level compared to existing IVirtualResource but it can be directly used to implement IVirtualResource, IModuleResource and IModuleResourceDelta. Visitor-style API can also be implemented based on the new virtual tree, but I have not found need for such API yet. This code is still "prototype grade" as it has only been superficially tested and is only integrated in IResourceDelta processing. If WTP developers find this patch interesting I will provide fully integrated patch together with unit tests. Please have a look and let me know what you think.
Created attachment 49420 [details] lazy virtual tree implementation VirtualTreeNode is the only interesting class. It implements "proto" virtual tree that can be used to construct IVirtualResource, IModuleResource and IModuleResourceDelta trees. VirtualTreeNode can be configured and/or extended to perform various tree trasformations (for example, "replace java source with output" or "add consumed dependent modules"). As I mentioned above, this patch does not include changes to IVirtualResource. I will implement these changes if WTP developers agree to accept the patch.
Created attachment 49421 [details] updated ResourceManager that fast IModuleResourceDelta This patch introduces new ModuleDelegate.getModuleResourceDelta(IResourceDelta) and shows how this method can be used to calculate module publish state without scanning scanning all IModuleResources of affected modules. Please not that this change does not provide any obvious performance improvements, at least for server plugins provided by WTP. Some additional infrastrure needs to be built before these plugins can be switched to use ModuleDelegate.getModuleResourceDelta. This patch also provides some UI to switch new delta processing on and off.
Created attachment 49422 [details] updated ComponentDeployable module delegate This is the last patch from me for today (at least I think so). It demonstrates how ComponentDeployable and J2EEFlexProjDeployable can use new virtual tree implementation to construct IModuleResource and IModuleResourceDelta.
*** Bug 122720 has been marked as a duplicate of this bug. ***
We have gone a different route using the flatcomponent API.
