Search Unity

Performance Reporting aims to be a suite of tools. At the moment, only exception reporting is available as a feature of our Performance Reporting service. This has lead to some confusion as developers often are looking for profiling data. In the future, we see Performance Reporting becoming a suite of tools for things like benchmarking and getting some lightweight profiling data.

How Performance Reporting fits in with Analytics, Cloud Build, and Collaborate

We often get questions about how Performance Reporting works with our other Unity Services. Our vision is clear, and we would like to share it with you now.


Analytics is about helping developers understand their players. Performance Reporting is about improving the health of your game. By bringing these two together, we can see how bugs impact your players.

In the future, you’ll be able to cross reference game session data with exceptions.  With this, we can correlate an increase in exceptions with the end of a session.

Cloud Build

Cloud Build is all about automating your build process so you can focus on your game. Performance Reporting’s most requested feature is Native crashes. One struggle for native crash support is getting the build symbols, so that the native crash reports are readable by humans.

Again, by bringing these two together, we can give you native crashes just by turning both the services on. The future we see here is native crashes with two clicks. Just enable Cloud Build and Performance Reporting.


Collaborate is all about seamlessly working on your project with a team. Part of good collaboration is having a clear overview of bugs that currently exist in your project. Performance Reporting will be able to use Collaborate’s project history to help narrow down where and when a bug was introduced.

Performance Reporting is now integrated into the editor

Previously, it took some effort to get started with Performance Reporting. These were the steps our beta users went through:

  • Learn the feature existed
  • Go to the website
  • Download the package
  • Install the package
  • Get your project ID
  • Add a few lines of code to your project

While we did our best to simplify this, it was still too hard.

We’re pleased to announce that in Unity Pro 5.4, new projects can enable Performance Reporting with one click.


The work here mostly involved translating C# into C++ , refining our algorithm for sending data and moving from the Unity WWW class to the UnityWebRequest class.

How the Performance Reporting client works

Performance Reporting sends reports with a behavior that works like this:

  • A map between fingerprint and exception is stored.
  • An exception comes in and gets fingerprinted.
  • If the fingerprint isn’t in the map, it is added, then an asynchronous HTTPS request is scheduled for that report ensuring PerfRep gets at least one report.
  • If the fingerprint already exists in the map, a counter is incremented.
  • If too many of the same exception have been observed (10,000), the data is flushed asynchronously via HTTPS, and the feature breaker trips for the session.
  • If too many different exceptions have been observed (100), the data is flushed asynchronously via HTTPS, and the feature breaker trips for the session.
  • When the client exits the game, the data is flushed asynchronously via HTTPS to the server.

When the feature breaker trips, we unregister the log callback so we don’t get any more reports this play through. Relaunching the game will start sending new reports. Usually when you reach one of these limits, you hit one of these cases:

  • There is an exception in the update loop.
  • A message that is variable with something like a time stamp, url with a query string, or temporary file name.

One challenge was the exit hook. Some platforms don’t give you any time; others do. The Desktop platforms will successfully send their final counts, but that might not always be the case with iOS.

Upgrading from the Performance Reporting Plugin

If you’re using Performance Reporting for a 5.3 or earlier project, upgrading  from the plugin to native editor is pretty straight forward. Just remove the package and any code you have referencing it, such as the initializing code. Then go to the Unity Services window shown above and click enable.

If you don’t remove the plugin, the new method will still work. However, both the plugin and editor integration will send a report, causing double counting and extra network traffic.

Performance Reporting Roadmap

The feedback we’ve gotten has been remarkably consistent. Developers want native crashes, and some more filtering and tagging options for the dashboard.

The good news is that we should have some better filtering options for the dashboard SoonTM. The also good, but never soon enough news, is that native crashes will probably be in 5.5 for iOS with other platforms to follow. Native crashes are a platform by platform battle, and we will do our best to get the ones we can into 5.5.

Another shift for Performance Reporting will be the what we’re calling the “Common Data Pipeline”. This is a platform that the editor will use to minimize network connections and link information between services.



Subscribe to comments

Comments are closed.

  1. Currently this is a bit useless to me, as you can’t filter by version number. So, although I patched most of the bugs in v1.8, there are many 1.7 versions in the wild, spamming thousands of errors, and filling up my log with reports that I have already fixed.

    The “filter” field seems like it could do the trick, but it only seems to filter on the error message itself, typing in a version number does nothing.

  2. Three questions:

    1. Does performance reporting work in WebGL?
    2. What does “client exits the game” mean for WebGL apps?
    3. Is there a way to manually trigger data flush to the server?

    Thank you!

  3. hola.sinfalta surespeto.nesecita……..ajuda por hecesprogramas.nesecitar para q activandos.hoye por favor

  4. “Performance Reporting’s most requested feature is Native crashes. One struggle for native crash support is getting the build symbols, so that the native crash reports are readable by humans.”

    What exactly are you referring to as “native crashes” ?

    Our game uses a mix of both C# code and native plugins (implemented in objective-c for iOS, Java for Android).

    When i think of native crashes, i mean crashes that occur in those plugins. I still want those to be reported so we know our game client crashed.

    A crash can also occur in other non-plugin code (e.g: OS code). We would still like to have that reported.

    Is this scenario currently covered? just making sure we’re referring to the same thing…

    1. Chris Lundquist

      June 24, 2016 at 4:17 pm

      For native crashes we mean crashes that happen in Objective C or C++ where the app is terminated.
      Both managed and native exceptions would be reported, they would just be handled a little differently code wise.

  5. Please guys, make this also accessible by code, either in the editor or at the beginning of the run-time, because we want the ability to make debug builds fast, without having to change settings manually. I guess this is great news for the newbies who still use visual scripting, but granting access to this functions is never a bad thing. Please reply

    1. Chris Lundquist

      June 24, 2016 at 4:33 pm

      You should be able to enable it / disable it via

      using UnityEditor.Connect;
      // ...

      CrashReportingSettings.enabled = false;

      The above modifies the UnityConnect.settings which gets baked into the runtime during the build process.

      1. Can I also change the id of the project dynamically? Say I have different branches of the same project, but i do not want their metrics to mix. One for development, one for testing, and one for production, you get the idea. How can I set the id’s dynamically? Including the id’s for Analytics, Ads, and so on.

        1. Chris Lundquist

          June 25, 2016 at 2:38 am

          I believe cloudProjectId is a read only attribute.

          For the crash reporting feature in particular, it uses PlayerSettings.bundleVersion to tag reports.

          Having a project per branch or environment isn’t the work flow we’re hoping for.
          That seems like making a Git repo per branch / env.

          I can see how it might be the only way at the moment to distinguish things across all our services though.

      2. Thanks, I found that other people have complained about this before:

  6. Hmm. Sounds like it’s still going to be a useless feature for quite a while. Can I get a partial refund for the Pro license I bought over a year ago? March 2017 will come before this feature is implemented. I was supposed to get a “Performance Reporting” service for 2 years.

    1. They are working with other pro license owners on extending cloud services.
      If they have not contacted you yet, you should get in touch with your local sales rep.

  7. Will this new native performance support allow us to enable reporting only for certain builds? We currently conditionally compile out reporting for editor and development builds as we expect them to be quite spammy! If there’s no code required to initialise the system, how would we accomplish this?

    1. Chris Lundquist

      June 24, 2016 at 4:36 pm

      The code in the response to Victor should help.
      The gist being:

      CrashReportingSettings.enabled = false;

  8. Why is it called Performance reporter while it is only an exception log ? It is more a Crash reporter.

    1. Chris Lundquist

      June 24, 2016 at 4:37 pm

      Because more features are in the works!