Community
Participate
Working Groups
From https://www.eclipse.org/forums/index.php/t/1091962/ It seems that XWT tries to locate some 'MyControl'BeanInfo Java classes while loading the 'MyControl' class. We don't use this feature in Papyrus. However, the classes we provide to override/disable the XWT features that we don't use doesn't skip this. I'm not sure when/why it happens, as we didn't notice that during the last optimization pass on XWT & Papyrus properties. To be investigated...
As far as I can tell, the expensive calls are done only once per metaclass: > [...] > Introspector.getBeanInfo(Class<?>) line: not available > Metaclass(AbstractMetaclass).initialize(Class<?>, IMetaclass) line: 685 > Metaclass(AbstractMetaclass).assertInitialize() line: 677 > Metaclass(AbstractMetaclass).newInstance(Object[]) line: 395 > [...] because our CachedMetaclassManager / CachedMetaclassService works as expected. So the observe performance issue should be a one-time issue, on Papyrus startup. However, the observed time (40 seconds?) is way higher than what I observe with a base Papyrus installation, so we may still try to optimize it - especially since we never provide a custom BeanInfo.
Unfortunately I'm not able to reproduce the issue. Loading the Appearance Tab for a class for the first time takes ~ 3 seconds of Class Loading (3.5s for the complete rendering). And Class Loading only happens once for each properties view control (Type/Class), so selecting other elements is much quicker after that initial loading. There is also not much we can do about the BeanInfo (It actually seems even worse when I try to skip the 'explicit bean info', taking 6.5 seconds instead of 3).
I can confirm that this is a one-time issue. We are using papyrus in our own target platform together with CDO and a lot of other stuff. I will try to find out what exactly is going on here and provide some details.
Well, the basic idea is that for each control class we use to render properties editors, XWT will have to load them reflexively. And for that, it will need to go through the entire ClassLoader of org.eclipse.papyrus.infra.tools, on which all Papyrus bundles depend (And which declares the Buddy-Policy) The reason is that all our classes are referenced via EMF Models (Properties Models) by qualified name, without any indication about the bundle that contains the class. So we rely on the Buddy-Policy to search all Papyrus Bundles, and whichever bundle may contribute to Papyrus. This worked fine 8 years ago when Papyrus contained (way) less than 100 Bundles, but since then, many bundles have been added, which significantly increases the cost of Buddy-Policy class-loading. Moreover, we have also reached the 200-Bundle limit that OSGi can keep in cache by default, so OSGi may have to unzip bundles again when looking for resources (And maybe java classes as well; I'm not sure). One solution to fix this would be to pre-load the classes when we know in which bundle they are located (Typically, they are located in the bundle that contributes the environment.xmi model to the corresponding Papyrus extension point; but not necessarily. Still, that should cover 90+% of the cases). This should be faster than always using the oep.infra.tools Class Loader (Even if we still need to keep this loader as a fall-back) Another solution would be to replace the rendering part of the Papryus Properties Views entirely, but that's a completely different story :)
We also have quite a few bundles in our application and some of them certainly depend on papyrus.infra. I found out that one of our bundles which is very common for all of our own other bundles also has a dependent policy. My investigation shows that for example org.eclipse.papyrus.infra.constraints Initially has 14 dependent bundles originating from papyrus iteself. But when it comes to XWT introspection another 250 dependent bundles have been added. I think this ist the major problem. So the effect at least in this extend is related to our own setup. I was able to remove the dependency policy in our bundle and now it seems to work more ore less smoothly. Thank you very much for investigation on this issue.
