Community
Participate
Working Groups
A WTP adopter noticed some extreme computation in the Add/Remove facets dialog and prompted me to take a look. In a smallish WTP workspace I opened the dialog and found that the RuntimeBridge is being called a whopping 1034 times. The current runtime bridge appears to be incredibly fast (maybe ~80ms first call, 1/8ms every other time) but this still accounts for about 1/4 to 1/2 of the time taken to open the dialog. Even a minor degradation in the bridge or in adopter extensions (or if the # of calls are relative to # of runtimes or facets) would cause a performance problem opening the dialog.
David, could you investigate? We should address this for the 2.0 release.
Created attachment 59918 [details] Patch caches runtime component information
It's not quite that easy, I am afraid. We cannot cache components in the BridgedRuntime because we have no way of knowing when the cached list gets stale. For instance if a user adjusts the runtime vm, that will change the runtime component (different component version). What we really need to do is analyze why that many calls are being made and to figure out a way (in the wizard) to reduce the number of calls. If the number of calls cannot be easily reduced, we can try caching in the context of the wizard, but I'd rather not do that.
This sounds like it needs some more thought and is too risky given 2.0 shutdown. Deferring.
Moving to 202.....
This target (and/or status) does not seem correct. Is it fixed in 2.0.2? Or ... does it need to be targeted to 3.0.1?
Pinging for this bug. Could we put this into plan for a release? This is still a problem for WTP adopters.
The best way to revive a bug that isn't going anywhere is to contribute analysis and a patch. See Comment #3. I will certainly take the time to review any proposed solution.
