Closed pcdavid closed 1 month ago
Here's a measure of the time just building the PacakgeNotFoundException
instances when loading the "Sirius Web" Papaya example:
After switching to a plain class implementing EMF's Resource.Diagnostic
directly, it's still invoked 20k times but but now accounts for ~1ms in total:
(I had to switch to YourKit's tracing mode, as in sampling mode it's not even measurable).
In
org.eclipse.sirius.emfjson.utils.GsonEObjectDeserializer.deserializeMultipleNonContainmentEReference
(among others) we try to resolve the resource part of a reference URI as an EPackage usinggetPackageForURI(String uriString)
.This works for the case where the reference URI is of the form e.g.
http://www.eclipse.org/emf/2002/Ecore#//EBoolean
, but will fail in most concrete cases where the reference URI will be something like52317c1f-0516-48b4-bad4-15a3a07aebe9#//path/to/some/element.1
. In such a casegetPackageForURI
keeps track of the error with:Unfortunately, the error type used,
PackageNotFoundException
is an actual Java exception, which is very costly to create (because offillStackTrace
). I'm not sure why thisResource.Diagnostic
(along with all the otherJsonException
subtypes) are exceptions, but just commenting out this line to avoid creating thousands of exceptions when loading a medium-sized model give a significant performance boost:Before (master, emf-json 2.3.9/master):
After (commented this.helper.getResource().getErrors().add(new PackageNotFoundException()))
Simply commenting out the code is probably too much, but replacing an exception with a plain
Resource.Diagnostic
object should get us most of the gain (I need to confirm).