| Performance problem: how to speed up loadPackage() in EPackageImpl class [message #1445734] |
Wed, 15 October 2014 17:45  |
Eclipse User |
|
|
|
Hi all--
I have finally gotten around to some detailed performance analysis of my EMF KML code, and discovered that during initialization, there is a roughly 550ms hit, and I've narrowed it down to a series of 150 - 200ms hits that are caused by this line in the generated code:
resource.load(null);
Is there anything I can do to make this more efficient? I know this is a vague question as I'm not including my complex EMF model definitions, but is there some area that I can look at? or should these be initialized in plugin activation in a separate thread so that the hit won't come when the user tries to load a KML file? Maybe that's a good workaround ...
thanks
Tamar
|
|
|
| Re: Performance problem: how to speed up loadPackage() in EPackageImpl class [message #1445933 is a reply to message #1445734] |
Thu, 16 October 2014 01:24  |
| Eclipse User |
|
|
|
Tamar,
Comments below.
On 15/10/2014 11:45 PM, Tamar Cohen wrote:
> Hi all--
>
> I have finally gotten around to some detailed performance analysis of
> my EMF KML code, and discovered that during initialization, there is a
> roughly 550ms hit, and I've narrowed it down to a series of 150 -
> 200ms hits that are caused by this line in the generated code:
>
> resource.load(null);
This is loading the serialized *.ecore. This may cause all dependent
models to load as well, and you'll generally find (I expect) that the
overall cost is dominated by class loader costs, not by the XMI
processing itself. If you change the GenPackage's Initialize by
Loading to false, does the code compile or is some byte code too big? I
suspect that really won't make the performance significantly better
though...
>
> Is there anything I can do to make this more efficient? I know this
> is a vague question as I'm not including my complex EMF model
> definitions, but is there some area that I can look at? or should
> these be initialized in plugin activation in a separate thread so that
> the hit won't come when the user tries to load a KML file? Maybe
> that's a good workaround ...
My instincts tell me this sounds like a class loader issue. This is
really the dominant cost for Eclipse startup in general and there's
pretty much nothing that can be done except load fewer classes, or try
to come up visually as quickly as possible and then load classes on
other threads so they're ready when the user is ready. You'll see for
example, jobs that initialize JDT, which take very long..
>
> thanks
> Tamar
>
|
|
|
|
| Re: Performance problem: how to speed up loadPackage() in EPackageImpl class [message #1447475 is a reply to message #1447085] |
Sat, 18 October 2014 06:45 |
| Eclipse User |
|
|
|
-- Off-Topic --
Hi Tamar,
Out of interest: Do you have the KML format converted to EMF and what 3D view are you talking about?
Thanks.
Tamar Cohen wrote on Fri, 17 October 2014 21:27Thanks Ed --
So I've regenerated and now my initialization time (which happens in a separate thread when the plugin is activated) has been cut from 530ms to 240ms, which is an improvement. Unfortunately the actual functionality of loading the kml and rendering it in the 3d view has been broken but hopefully I can track that down!
I agree that it's probably the Java classloading time that we have to wait for, but 240ms (or even 530) in a separate thread is not noticeable at all.
thanks
Tamar
|
|
|
Powered by
FUDForum. Page generated in 0.03991 seconds
Home