Android Profiler and Coroutines

Unity Engine
,
1

I’m running into a consistent issue which suggests I don’t understand something going on under the hood. I’m profiling my game on my android device and trying to sort out any spikes. Here’s my issue:

  1. Across several different coroutines (regardless of which coroutine and what’s in the coroutine), most of the time the coroutine runs fine, no spikes, all is well.
  2. A significant percentage of the time though, the coroutine profiles differently, and under the coroutine I get File.Read, File.Open, File.Seek. See screen shot.

1872×650 132 KB

To reiterate, most of the time my coroutines run normal, no spikes, I don’t see any File.X references. Occasionally though, I see the same coroutine run, a spike, and every time I see the spike, I see the File.X reference under the coroutine, regardless of which coroutine it is in my game.

Anyone have any idea what’s happening? GC? Spikes are anywhere from the 18ms to 40ms variety, so really significant in a game that otherwise runs at 60fps.

Here’s the profiled coroutine, but like I said, it seems to be systemic to every coroutine in my game (I chose this one since it’s the simplest coroutine and I still see this happen)?!

    IEnumerator CountDown()
    {
        countDownText.text = "3";
        audioSource.PlayOneShot(countDownSound);

        yield return new WaitForSeconds(1);

        countDownText.text = "2";
        audioSource.PlayOneShot(countDownSound);

        yield return new WaitForSeconds(1);

        countDownText.text = "1";
        audioSource.PlayOneShot(countDownSound);

        yield return new WaitForSeconds(1);

        countDownText.text = "!";
        audioSource.PlayOneShot(gameStartSound);

        matchStarted = true;

        yield return new WaitForSeconds(1);
        countDownText.text = "";
    }

Any help is greatly appreciated! Just a few more spikes until this guys running happily!

2
  1. What Unity version are you using ?
  2. Did you try to profile the game in the editor? does it produce the same results?
  3. A bit of a long shot, but could it possibly be related somehow to the audioSource playback? try to remove those calls, just as a test, and profile again. See if that makes any difference.
  4. Are you using mono or il2cpp ?

In any case, the File.XX calls don’t seem to be the cause of spikes (the coroutine itself is the one that takes up most of the time, according to the profiler).

3
  1. 2017.1
  2. Will go try.
  3. Will double check.
  4. Mono.

I actually had a question about that. I assumed there was no way the coroutine itself could cause such large spikes and figured it was the anomalous items (File.X) that must be causing it even though they don’t show as taking much time (since they ALWAYS show up with the spike). That assumption is wrong? Simply running the coroutine is seriously eating up that much time? That’s a REALLY basic coroutine, not doing anything particularly exotic or fancy. How on earth is a coroutine generating that much of a spike?

Appreciate the reply, I’ll go try #2 and #3.

EDIT: You might be right, I removed audioSource.PlayOneShot references (virtually all of my coroutines use it), and I’m not initially seeing the same spikes any more. Any idea why my very basic caching of an AudioSource and calling PlayOneShot on it would cause the spike? I’ll go investigate audio compression/file format issues, that’d be my guess.

4

Welp, you sent me in the right direction, thanks!

It’s not so much audioSource that was the problem, it was my audio file default settings. The reason I saw File.X everytime there was a spike is because it was actually trying to load the audio file on the fly, causing the spike. Changed audio file defaults, spikes gone! Thanks, really appreciate it! Just a few more spikes to get this thing smoothed out, almost there…

1 Like