Quickstart-unity: GenerateXmlFromGoogleServicesJson.CheckConfiguration performance

Created on 14 Apr 2020  路  7Comments  路  Source: firebase/quickstart-unity

Please fill in the following fields:

Unity editor version: 2019.3.0f6
Firebase Unity SDK version: 6.13.0
Source you installed the SDK (.unitypackage or Unity Package Manager): Unity Package Manager
Firebase plugins in use (Auth, Database, etc.): Remote config, Analytics, Messaging
Additional SDKs you are using (Facebook, AdMob, etc.): AdMob, PlayGames services, UTNotifications
Platform you are using the Unity editor on (Mac, Windows, or Linux): Windows
Platform you are targeting (iOS, Android, and/or desktop): Android
Scripting Runtime (Mono, and/or IL2CPP): IL2CPP

I downloaded lastest External Dependency Mnager and Firebase - all instaled via Package Manager. After it my editor becomes unusable. Everytime when I hit play it will call GenerateXmlFromGoogleServicesJson.CheckConfiguration method - and this methot take 10 sec to run. Here is my profiller snapshot taken in editor with deep profile https://c2n.me/470IGYN.png https://c2n.me/470J06b.png - I understand, that is requiered to generate this cfg files, but is necessary to refresh it every time whan I enter playmode? Or is there implemented some kind of caching, which is just not working in my case?

duplicate bug

Most helpful comment

Have the same problem with Unity 19.3, Firebase 6.13 from UPM. I believe it would be hard to reproduce the issue with any small example, because the part of slowdown happens because of AssetDatabase.FindAssets() usage. Which is sloooow only on reasonably large projects. Each call is like 2-3 seconds.

I think RadekMikulkaAG is absolutely right here: it's probably better not to optimize this, but to make an option of not running this code at all. In the end, when no plugins have been changed, it does nothing and takes 10-20 seconds. So my suggestion is to make two options, like:

  • Run resolvers/version handlers only at build time
  • Run resolvers/version handlers only manually

All 7 comments

This issue does not seem to follow the issue template. Make sure you provide all the required information.

Hi @RadekMikulkaAG !

I'm sorry to hear that you're having an issue.

Generally you shouldn't experience extended slowdown before your game runs in the editor, so would you mind helping us work out what's going on?

The first thing to do is to see if you can reproduce this error in one of the quickstarts included in this GitHub repository. Here's Remote Config , Messaging, and Analytics. An interesting note is that Remote Config is the only one of these three that technically does anything on the desktop, so it would be interesting if you tested Remote Config and one other to see if you have a different experience.

Do make sure that you integrate the SDK the same way (as in via the PackageManager).

Whether or not this does anything, it's also useful to follow the additional instructions here. Namely, after installing EDM4U and Firebase via the Unity Package Manager, you should be able to delete any folders in the Assets directory called Firebase, Parse, PlayServicesResolver, and ExternalDependencyManager (try using the uninstaller mentioned in that doc link first).

If you can reproduce this in the quickstarts, that's really ideal. It helps us create a solid repro environment on our local machines. If you don't see it in the quickstarts, we'll have find some other way to reduce the amount of variables in flight.

Let me know what you find!
--Patrick

Ok, I created sample project where you can easily simulate this issue - project contain only firebase analytics and nothing else. (https://drive.google.com/open?id=1aLMoNq2ygUsqmDg33qC_ttk5UrXGIcJ6)

1) Open scene called "xxx"
2) Hit play
3) After while there will appear error log in console (There is simple script Test.cs which is loging time in ms passed from starting playmode to 10th frame)

  • I hope you will see how big this number is (in my case is over 20 000 ms on older intel i5)
  • there is alo folder "Test" which contains multiple "google-services" files - I found that this lag depends on count of "google-services" files in project (I know that file should by only one, but for testing purposes and demonstration of this lag is better to have more those files included)

As I sad - I understand that there is requiered to run GenerateXmlFromGoogleServicesJson.CheckConfiguration() but is really necessary to run it every time when I enter playmode? Simple solution for this whole problem is do not call GenerateXmlFromGoogleServicesJson.CheckConfiguration everytime when entering playmode, but only while resolving packages or sometking like that?

I have the same issue

Unity 2019.2.21, Firebase 6.12.0 and 6.13.0 (.unitypackage and dependency)

Have the same problem with Unity 19.3, Firebase 6.13 from UPM. I believe it would be hard to reproduce the issue with any small example, because the part of slowdown happens because of AssetDatabase.FindAssets() usage. Which is sloooow only on reasonably large projects. Each call is like 2-3 seconds.

I think RadekMikulkaAG is absolutely right here: it's probably better not to optimize this, but to make an option of not running this code at all. In the end, when no plugins have been changed, it does nothing and takes 10-20 seconds. So my suggestion is to make two options, like:

  • Run resolvers/version handlers only at build time
  • Run resolvers/version handlers only manually

I've tried changing Version Handler, Android Resolver and iOS Resolver to manual via Assets -> External Dependency Manager -> [one of the options listed earlier] -> Settings. Problem still persists.

As @L4fter pointed out, this is most likely the same issue as reported in #639

To add, my issue is not only when pressing play but also right after making any changes to code and switching back to the editor.

I've attached this issue to the same ticket as #639 within our internal bug ticketing system. Thanks for all of the info. For now I'm going to close this as a duplicate issue, but we may re-open this in the case it's not the same problem after further investigation.

Was this page helpful?
0 / 5 - 0 ratings