Closed pcdavid closed 3 weeks ago
I think we can assume that when JsonResourceImpl.useID
is set, the idToEObjectMap
is correctly filled with all the resource elements' ids (otherwise that's a bug) and if the requested id is not found there we can return null
immediatly.
When
JsonResourceImpl.getEObjectByID(String id)
is called with an id which is not present in the resource and not found in the localidToEObjectMap
, it delegates to the default implementation from EMF:return super.getEObjectByID(id)
.However because we use our own
idToEObjectMap
instead of EMF'sintrinsicIDToEObjectMap
, that map (from EMF'sResourceImpl
) isnull
, which makes EMF fallback to a very costlyfor (TreeIterator<EObject> i = getAllProperContents(getContents()); i.hasNext(); ) {...}
.This scenario is actually very common. For example if a project contains 25 documents, looking for an EObject in the last one (in
ResourceSet.getResources()
order) will try and fail, slowly, on the first 24 documents before finding the right one.In the context of Sirius Web,
DefaultObjectSearchService.getObject(IEditingContext, String)
can be called a lot, with EObject ids (which will be found, even if in the "last" resource looked into), but also with representation ids of editing context ids, in which cases we will look into all EMF resources's contents for nothing before searching for representations/editing contexts.