Bug 115704 - The performance of loading MSL resources with errors could be significantly improved
Summary: The performance of loading MSL resources with errors could be significantly i...
Status: RESOLVED FIXED
Alias: None
Product: GMF-Runtime
Classification: Modeling
Component: General (show other bugs)
Version: 1.0   Edit
Hardware: PC Windows XP
: P3 normal
Target Milestone: ---   Edit
Assignee: Christian Vogt CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed, performance
Depends on: 124373
Blocks:
  Show dependency tree
 
Reported: 2005-11-09 16:28 EST by Dusko CLA
Modified: 2010-07-19 12:24 EDT (History)
0 users

See Also:


Attachments
patch for org.eclipse.gmf.runtime.emf.core (7.34 KB, patch)
2006-01-19 14:48 EST, Christian Vogt CLA
no flags Details | Diff
patch for org.eclipse.gmf.runtime.emf.core (8.61 KB, patch)
2006-01-20 13:32 EST, Christian Vogt CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dusko CLA 2005-11-09 16:28:19 EST
Methods ResourceUtil.load(...) and MSLEditingDomain.loadResource(...) unload 
resources that threw an exception during their load. The MSL resources throw 
exception at the end of the load if there were any errors during the load, 
unless run in the compatibility mode.

So, the logic goes like this:
1) ResourceUtil.load(...) and MSLEditingDomain.loadResource(...) initiates 
load of the MSL resource.
2) The resource loader encounters an error. In one very common use case 
(missing schema) that error is encountered at the very beginning. The loader 
puts the error in the error list and continues.
3) The resource is eventually completely loaded.
4) The code checks if there are any errors in the error list. Since there is 
one, an exception is thrown.
5) The load was not in the compatibility mode. The resource gets unloaded.

In my example, I had a customer model with an unrecognized schema. Initially 
we try to open it using ResourceUtil.load(...) without using the compatibility 
mode. In my environment it takes 20 seconds to load it and then almost another 
20 seconds to unload. Total 40 seconds for the load(…) call to come back and 
the resource is not loaded at the end.

Obviously this could be optimized at least for the MSL resources. The 
ResourceUtil.load(...) and MSLEditingDomain.loadResource(...) could pass down 
to resource implementation some flag to indicate that it should throw the 
exception right away and not at the end. Of course, the flag would not apply 
in the compatibility mode case since exceptions are not thrown in that case. 
The performance improvement in my case would be going down from 40 seconds to 
around 5 seconds.
Comment 1 Christian Vogt CLA 2006-01-19 14:48:49 EST
Created attachment 33288 [details]
patch for org.eclipse.gmf.runtime.emf.core

A new load option has been added that will abort resource load as soon as an error occurs. Since the MSLEditingDomain will unload any resource which encounters an error, this option is defaulted to true for resources being loaded by the MSLEditingDomain.

The new load option is MSLResource.OPTION_ABORT_ON_ERROR
Comment 2 Christian Vogt CLA 2006-01-20 13:32:24 EST
Created attachment 33368 [details]
patch for org.eclipse.gmf.runtime.emf.core

updated to keep consistent with throwing Resource.IOWrappedException's
Comment 3 Vishy Ramaswamy CLA 2006-01-21 14:09:54 EST
reviewed and applied the patch
Comment 4 Eclipse Webmaster CLA 2010-07-19 12:24:18 EDT
[GMF Restructure] Bug 319140 : product GMF and component
Runtime EMF was the original product and component for this bug