Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » .ecore, XMLResource IDs and Xtext Builder(Performance when loading a lot of .ecore often)
.ecore, XMLResource IDs and Xtext Builder [message #1544159] Sat, 03 January 2015 16:25 Go to next message
Andreas Graf is currently offline Andreas GrafFriend
Messages: 211
Registered: July 2009
Senior Member
Dear all,

we are seeing some performance problems with Xtend2/Xtext projects that reference other projects/bundles that include .ecore's and we would like to discuss if the following analysis is correct.

In an RCP/Eclipse application that we implement, we have a lot of Xtext/Xtend2 projects and the Xtext builder tries to validate .ecore in referenced projects (for us, amongst others, this is Artop's gautosar.ecore). We see a lot of time spent here and an analyis with Yourkit gives the trace in the attached screenshot.

It seems that a lot of time is spent in org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObjectByID(String)

If we have a look at .ecore files, they don't seem to use XML IDs, do they? So that would mean that each reference lookup would cause a full model traversal in getEObjectByID?

Is it correct that XMLResource.OPTION_DEFER_IDREF_RESOLUTION would avoid that by trying to defer the reference resolution?

So would it make sense if
org.eclipse.emf.ecore.xmi.impl.EcoreResourceFactoryImpl.createResource(URI)
would set that option and could that improve our performance case?

Regards,

Andreas

[Updated on: Sat, 03 January 2015 16:27]

Report message to a moderator

Re: .ecore, XMLResource IDs and Xtext Builder [message #1547133 is a reply to message #1544159] Mon, 05 January 2015 08:47 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30700
Registered: July 2009
Senior Member
Andreas,

Comments below.

On 03/01/2015 5:25 PM, Andreas Graf wrote:
> Dear all,
>
> we are seeing some performance problems with Xtend2/Xtext projects that reference other projects/bundles that include .ecore's and we would like to discuss if the following analysis is correct.
>
> In an RCP/Eclipse application that we implement, we have a lot of Xtext/Xtend2 projects and the Xtext builder tries to validate .ecore in referenced projects (for us, amongst others, this is Artop's gautosar.ecore). We see a lot of time spent here and an analyis with Yourkit gives the trace in the attached screenshot.
>
> It seems that a lot of time is spent in org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObjectByID(String)
Yes, the default implementation of this is very slow. But note from the
call stack that it calls this first:

public EObject getEObject(String uriFragment)
{
int length = uriFragment.length();
if (length > 0)
{
if (uriFragment.charAt(0) == '/')
{
return getEObject(SegmentSequence.create("/",
uriFragment).subSegmentsList(1));
}

so you really must have an ID not a fragment path; a fragment path
starts with a '/'. When the ID is processed it does

protected EObject getEObjectByID(String id)
{
Map<String, EObject> map = getIntrinsicIDToEObjectMap();
if (map != null)
{
EObject eObject = map.get(id);
if (eObject != null)
{
return eObject;
}
}

So if you've called
org.eclipse.emf.ecore.resource.impl.ResourceImpl.setIntrinsicIDToEObjectMap(Map<String,
EObject>) with a map, it would look the ID up in that map, and if it
doesn't find it in the map, it will build a map so the next look-up is
fast. In combination with
org.eclipse.emf.ecore.xmi.XMLResource.OPTION_DEFER_IDREF_RESOLUTION that
should result in the resource's contents being traversed only once at
the end of XML loading rather than once per ID look-up. That should
perform well.


>
> If we have a look at .ecore files, they don't seem to use XML IDs, do they? So that would mean that each reference lookup what cause a full model traversal in getEObjectByID?
As you've noted, *.ecore files don't use intrinsic IDs, nor does the
Ecore model itself define any, so this performance problem must come
from some other type of resource...
>
> Is it correct that XMLResource.OPTION_DEFER_IDREF_RESOLUTION would avoid that by trying to defer the reference resolution?
Yes, in combination with using setIntrinsicIDToEObjectMap (normally
something you'd do in the resource factory).
>
> So would it make sense if
> org.eclipse.emf.ecore.xmi.impl.EcoreResourceFactoryImpl.createResource(URI)
> would set that option and could that improve our performance case?
I'd suggest setting a breakpoint in
org.eclipse.emf.ecore.resource.impl.ResourceImpl.getEObjectByID(String)
to determine which type of resource is involved, and once you determine
that (I doubt its *.ecore), determine which resource factory creates it
and using setIntrinsicIDToEObjectMap in that factory.
>
> Regards,
>
> Andreas
>
Re: .ecore, XMLResource IDs and Xtext Builder [message #1547359 is a reply to message #1547133] Mon, 05 January 2015 11:31 Go to previous messageGo to next message
Andreas Graf is currently offline Andreas GrafFriend
Messages: 211
Registered: July 2009
Senior Member
Hi Ed,

thanks for the reply. I saw the code fragment dealing with "/" in the code, but forgot to mention it.

I think the culprit may be autosar.ecore. Artop generates all of the .ecore actually with ids:

<eStructuralFeatures xsi:type="ecore:EReference" name="hwType" eType="#_mmtG_1284267183">

... and

<eClassifiers xsi:type="ecore:EClass" xmi:id="_mmtG_1284267183" name="HwType"
eSuperTypes="#_mmtG__111740144 #_mmtG_1834162185">

Would that be dealt efficiently when the resource is created by the standard .ecore Resource Factory?

Regards,

Andreas

[Updated on: Mon, 05 January 2015 12:54]

Report message to a moderator

Re: .ecore, XMLResource IDs and Xtext Builder [message #1547509 is a reply to message #1547359] Mon, 05 January 2015 13:22 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30700
Registered: July 2009
Senior Member
Andreas,

Comments below.

On 05/01/2015 12:31 PM, Andreas Graf wrote:
> Hi Ed,
>
> thanks for the reply. I saw the code fragment dealing with "/" in the
> code, but forgot to mention it.
>
> I think the culprit may be autosar.ecore. Artop generates some of the
> .ecore actually with ids:
Hmm, that's kind of questionable...
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="hwType"
> eType="#_mmtG_1284267183">
>
> .. and
>
> <eClassifiers xsi:type="ecore:EClass" xmi:id="_mmtG_1284267183"
> name="HwType"
> eSuperTypes="#_mmtG__111740144 #_mmtG_1834162185">
>
> Would that be dealt efficiently when the resource is created by the
> standard .ecore Resource Factory?
No. Perhaps better that Artop not generate such an *.ecore.
>
> Regards,
>
> Andreas
>
Previous Topic:Is there a known vulnerability with concurrent calls to ResourceSetImpl.add(Resource)?
Next Topic:[CDO] Is CDOMergingConflictResolver really called back when conflicts occur ?
Goto Forum:
  


Current Time: Mon Dec 16 12:27:06 GMT 2019

Powered by FUDForum. Page generated in 0.02356 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top