Fireperf: [Startup improvement] lazy initialize expensive objects in GaugeManager #3011
Conversation
Coverage ReportAffected SDKs
Test Logs
NotesHTML coverage reports can be produced locally with Head commit (396a33c0) is created by Prow via merging commits: 79975f0 3aa1bb7. |
Binary Size ReportAffected SDKs
Test Logs
NotesHead commit (396a33c0) is created by Prow via merging commits: 79975f0 3aa1bb7. |
I think at this point, it will work if Cpu and Memory gauge collectors are not singletons. The point of making these two being singletons is to make sure there is only one instance of each in the environment if other classes want to use them. |
Honestly, the only reason they are singletons is not to have redundant collectors of such metrics. But, given the fact they are being used only by the gauge manager, they don't have to be singleton. I would prefer for us to remove them to be singletons. Do you know the complexity in making them non-singleton? |
It should be quick and easy, unless it breaks a lot of tests which I don't expect to happen. Just updated PR with removal of singleton |
|
/test smoke-tests |
1 similar comment
|
/test smoke-tests |
As per b/201001743, the goal is to "Optimize SessionManager getInstance() to check of session enabled flags before initializing gaugeManager".
Why we can't lazy initialize GaugeManager
Currently no matter if verbose session is turned on or off, a method in
GaugeManageris guaranteed to be called inFirebasePerfProvider.attachInfo(). Specifically,FirebasePerfProvider.attachInfo()callsSessionManager.updatePerfSessionwhich callsSessionManager.startOrStopCollectingGauges, which then checks if verbose session is on, if yes it callsgaugeManager. startCollectingGauges, otherwise it callsgaugeManager.stopCollectingGauges.Therefore
GaugeManagermust be initialized.But we can lazy initialize expensive objects in GaugeManager
There are 3 relatively expensive objects in
GaugeManagerthat are not used when verbose session is off, but they are currently eagerly initialized. This PR just makes these 3 objects lazy, using a helper class from firebase-components.Additional optimization
Also swapped a
String.replaceAlltoString.replacefor very slight improvement.Other changes
Changed CpuGaugeCollector and MemoryGaugeCollector from singletons to normal objects (since they are only owned by GaugeManager which is a singleton already)