Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 369271 - [xbase][performance] Mark some services as singleton for an easy performance gain
Summary: [xbase][performance] Mark some services as singleton for an easy performance ...
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.3.0   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: M5   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-20 13:51 EST by Sebastian Zarnekow CLA
Modified: 2017-09-19 17:45 EDT (History)
2 users (show)

See Also:
sebastian.zarnekow: juno+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Zarnekow CLA 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 CLA 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 CLA 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 CLA 2012-01-23 06:22:13 EST 
Pushed some singleton-annotations to master
Comment 4 Knut Wannheden CLA 2012-01-23 07:39:15 EST 
Just out of curiosity: What was the actual test case for the benchmarks?
Comment 5 Sebastian Zarnekow CLA 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 CLA 2012-01-30 05:33:47 EST 
Closing this as the important types have been marked with @Singleton
Comment 7 Karsten Thoms CLA 2017-09-19 17:34:40 EDT 
Closing all bugs that were set to RESOLVED before Neon.0
Comment 8 Karsten Thoms CLA 2017-09-19 17:45:49 EDT 
Closing all bugs that were set to RESOLVED before Neon.0