Community
Participate
Working Groups
Creation of URIs seem to be the mein bottle neck when loading JvmTypes. We should try to avoid creating URIs. @Sebastian: Could you please attach your findings and mesurements to this bugzilla?
See TypeFactoryBenchmark in org.eclipse.xtend.caliper WITH URIs Scenario{vm=java7, trial=0, benchmark=Parse, implementation=Asm3CommonTypes, type=OBJECT} 41668.26 ns; ?=8504.19 ns @ 10 trials Scenario{vm=java7, trial=0, benchmark=Parse, implementation=Asm3CommonTypes, type=STRING} 216503.80 ns; ?=6839.81 ns @ 10 trials WITHOUT STRINGS that look like URIs: Scenario{vm=java7, trial=0, benchmark=Parse, implementation=Asm3CommonTypes, type=OBJECT} 19047.23 ns; ?=5700.25 ns @ 10 trials Scenario{vm=java7, trial=0, benchmark=Parse, implementation=Asm3CommonTypes, type=STRING} 147902.30 ns; ?=3729.53 ns @ 10 trials The latter was taken with a patched variant of the classes from org.eclipse.xtext.common.types.access.binary.asm where no URIs have been used but plain Strings were produced. These were added to a HashSet to make sure that the vm does not optimize the operation away. Taking into account that we almost always have a valid unique selector available that could be used as an internal identifier, the excessive string ops in #getURI can also be cleaned. Without these, we end up at at something closer to these numbers: Scenario{vm=java7, trial=0, benchmark=Parse, implementation=Asm3CommonTypes, type=OBJECT} 11538.43 ns; ?=105.42 ns @ 4 trials Scenario{vm=java7, trial=0, benchmark=Parse, implementation=Asm3CommonTypes, type=STRING} 124029.85 ns; ?=3290.40 ns @ 10 trials which appears to be almost twice as fast as the implementation that uses cached proxies. It seems worthy to dig deeper into that topic.
Related bug #432168
@Sebastian: Do you have something that could make it for 2.6? If so please add the whiteboard flag again.
No, unfortunately not.
