Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369271

Summary:	[xbase][performance] Mark some services as singleton for an easy performance gain
Product:	[Modeling] TMF	Reporter:	Sebastian Zarnekow <sebastian.zarnekow>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	knut.wannheden, sven.efftinge
Version:	2.3.0	Flags:	sebastian.zarnekow: juno+
Target Milestone:	M5
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Sebastian Zarnekow

2012-01-20 13:51:14 EST

I marked the following services as singleton on two different machines and got an 2% to 15% performance win depending on the numbers that I compared (best vs worst, worst vs worst, worst vs best, 2x5 runs with current state and with @singleton present)

Specifically these services are:

common.types.util
  .Primitives
  .RawTypeHelper
  .SuperTypeCollector
  .TypeArgumentContextProvider
  .TypeConformanceComputer
  .TypeReferences
  .VisibilityService

xbase.scoping.featurecalls
  .DefaultFeaturesForTypeProvider
  .JvmFeatureSignatureProvider
  .XConstructorProvider

xbase.typing
  .SynonymTypesProvider

xtext.resource
  .FileExtensionProvider

Please review that list to make sure that I did not miss any state in those services and that the measured performance improvements are really there and were no accidentally experienced numbers.

The motivation for this 'experiment' was a CPU snapshot which rendered itself useless since almost all time was summarized under XbaseScopeProvider#newDefaultFeatureDescriptionProvider and #newSugarDescriptionProvider

Comment 1 Sven Efftinge

2012-01-23 05:21:32 EST

When marking a service as singleton all transitive reps become defacto singletons. I wonder whether we want to explicitly mark everything as singleton or just the important top level components. 

As most of our injected services are stateless, marking all of them @Singleton sound like a good idea. I'm just a bit afraid of those cases where we accidentally introduced state... Those bugs are hard to find.

Comment 2 Sebastian Zarnekow

2012-01-23 05:48:36 EST

+1 for marking all the stateless services as singleton

We could write a unit test which inspects the injector for all singleton bindings and validates that no service is used which is not a singleton and that no field is declared which looks like state. Should be straight forward to implement with the binding SPI and / or the common types.

Comment 3 Sebastian Zarnekow

2012-01-23 06:22:13 EST

Pushed some singleton-annotations to master

Comment 4 Knut Wannheden

2012-01-23 07:39:15 EST

Just out of curiosity: What was the actual test case for the benchmarks?

Comment 5 Sebastian Zarnekow

2012-01-23 07:42:01 EST

I used the total execution time of org.eclipse.xtext.xtend2.ui.tests.performance.PerformanceTest and the number that is printed in assertFasterThen(..) as a simple heuristic.

Comment 6 Sven Efftinge

2012-01-30 05:33:47 EST

Closing this as the important types have been marked with @Singleton

Comment 7 Karsten Thoms

2017-09-19 17:34:40 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 8 Karsten Thoms

2017-09-19 17:45:49 EDT

Closing all bugs that were set to RESOLVED before Neon.0