200,000 thousand plug-ins is a lot.
There is no fundamental limit on the number of plug-ins that I know
of (apart from the fact that each plug-in must have a unique identifier
represented by a long (eight byte) integer. However, when the platform
core team is doing performance work, we tend to think of the 10,000 plug-in
ballpark as a good upper bound test case. We know of very few existing
applications with more than about 4,000 plug-ins.
There is a larger performance hit on
the first invocation of the platform on a given plugin configuration. On
first run we parse plugin.xml files, generate OSGi manifests as necessary,
and "resolve" the plug-in dependencies to make sure each plug-in
has its dependencies satisfied. This is relatively expensive. If
you pre-generate OSGi manifests and ship them with your plug-ins this will
save a big part of this cost. On subsequent runs, we load much of
this information as necessary from a compact binary cache. This will still
impose a performance cost relative to the number of plug-ins on startup,
but it is much faster than first startup. There has been some work
in Eclipse 3.1 to improve caching of the extension registry (where extensions
and extension points are stored), and there is more work planned to reduce
the footprint and/or use lazy caching of the OSGi data structures in the
Apart from startup, the number of plug-ins
should have no effect on performance other than memory footprint. With
the lazy extension cache in Eclipse 3.1, you may pay some extra cost if
you get a cache miss when accessing an extension and it has to be loaded
from disk. This is a pure space/time tradeoff, and there are system properties
you can set to turn this caching off. In any case, increasing Java heap
size is certainly recommended for large scale applications.
I encourage you to experiment with running
an application with that many plug-ins and report results and further questions
to the platform-core-dev mailing.
Eric Morter <emorter@xxxxxxxxxx> Sent by: platform-dev-admin@xxxxxxxxxxx
10/12/2004 04:02 PM
Please respond to
concerns with several document plug-ins
I'm looking at scenario where I'll be deploying Eclipse
Information Center mode. The Info Center may be running a combination
600 to 200,000 plug-ins and fragments, depending on what customers
install. Understandably, I'm concerned that this may affect performance.
Does anyone have any idea how many plug-ins Eclipse can reasonably handle
before performance starts suffering? Would the effects be limited
start-up time, as several hundred plugin.xml and fragment. xml files are
parsed, or would performance over the entire run of the application be
affected? Is there anything that could be done to improve performance
this case, like increasing the JVM heap size?
platform-dev mailing list