Community
Participate
Working Groups
We make 2141 method invokes and 180 field gets and 180 sets to the target VM during open of UserAdmin.java. If we can reduce this figure by using caching (to avoid repeated reflection lookup calls) and also studying the breakdown of the 2141 more closely we can pick up a performance saving. This bug is to track the progress of this item
Created attachment 17679 [details] Breakdown of target VM calls Spreadhsheet of breakdown of target VM calls after methods and fields are always cached, together with comments as to how some of these can be analyzed further to reduce the number of wire trips
A number of changes: Target VM methods are always cache'd to avoid the need for explicit caches which existed before. EnumerationProxy changed to not do an isAssignableFrom(...) check Specific JFC changes are: ComponentManager changed so setComponent and setParentContainer are combined into a single method call ComponentManager changed so initial bounds come back on the CL_REFRESHED packet and don't require an explicit query ComponentProxyAdapter changed so the initial query of visible and location are only done if required (i.e. if it's on the free form and has been explicitly altered by the edit part) ContainerProxyAdapter changed so fewer calls are made to getLayout(). This is done to determine things like layout policy factories, however if we have an explicit property setting for layout then no target VM call is required so the code is optimized to reduce the method calls The total number of trips from the IDE to the target VM is reduced from 2141 to 1208 for the UserAdmin.java testcase
These were missed originally as being done for 1.1M1
