Community
Participate
Working Groups
the performance trace in bug# 65638 indicates a significant amount of time is spend in initializing the pde class path container (69%). This should be further analyzed.
seems like rebuilding the pde model is reparsing plugin.xmls and regen'ing manifests etc etc. This is done every time regardless of whether there were changes. It seems this whole process is quite heavy and could benefit from some level of caching.
>This is done every time regardless of whether there were changes. every time meaning upon every startup, correct?
right. every startup it appears that some amount of manifest regeneration is being done.
I have already logged a bug report regarding this issue (bug 63367). This is definitely a step backwards as far as PDE is concerned from 2.1. In 2.1, we were able to use RegistryCacheReader and RegistryCacheWriter to read/save target platform data and reuse it if the target platform underwent no changes from invocation to invocation. This gave us great improvement for WSADIE, etc. We don't have an equivalent plan for the new runtime. Is there anything equivalent that Core can provide for us to use/copy/subclass/whatever to cache state?
suggest you close one of the bugs as a dupe. StateReader and StateWriter are not API but you can copy the code to persist your state. Similarly, the RegistryCacheReader and RegistryCacheWriter are not API but can be copied and used as you need. I believe that in both cases they are not doing anything internal/special. That is, you can take these as guides as to how to persist the data or copy them outright. As discussed previously, we are shying away from having the runtime provide tooling specific API/function. I bulks up the code, confuses the API and inhibits our ability to do optimizations and remain lean. We're happy to supply code, advice and other help.
Thanks Jeff. As always, we will take you up on your offer. Will look at the StateReader/StateWriter classes. Even with the old runtime, we maintained our own trimmed-down version of these cache reader/writer classes. So no problems with copying code here <g>. Too late for this item to go into RC2. Definitely a top (and hopefully only) candidate for RC3, as without caching, performance is worse off than in 2.1.
*** Bug 63367 has been marked as a duplicate of this bug. ***
*** Bug 66320 has been marked as a duplicate of this bug. ***
Actually, there is API for clients saving/restoring their states: StateObjectFactory#write/readState.
Thanks Rafael. How do you cache extensions?
Extensions/extension points are a separate issue, the API I mentioned above is intended for saving states (bundle descriptions and constraints between them). That would avoid unnecessary manifest generation. However, we don't provide API for saving/restoring an extension registry cache (we keep the two models in separate places). You will have to have a look at the classes Jeff mentioned. Beware that you need to keep the extension registry model in sync with the state (if the state cache is outdated, the extension registry must be discarded as well).
*** Bug 78747 has been marked as a duplicate of this bug. ***
Fixed. PDE now uses the runtime support to write/read the state for the target platform. As for all other data not contained within the state, e.g. libraries, extensions and extensions points, etc., PDE now uses our own caching mechanisms for these objects. The litmus test whether to throw away the cache and recompute anew is if a hash function of the timestamps of all plugin.xml/fragment.xml/MANIFEST.MF files in the target platform returns a value that is different from the cached one. Will attach numbers later on today to illustrate the before and after on a huget target platform.
