EventSystem.Update() causes spike in CPU only on the initial touch / click

Why does the EventSystem.Update() take so long to process for the first initial input touch / click ?
Profiling my game on Android shows that the initial EventSystem.Update() takes about 200ms to complete and generates a few KB of garbage… I tested a brand new empty project with just a button and it’s the same thing. High % of cpu usage for the initial touch then breezes through the rest of the clicks.

I disabled the EventSystem and instead made a simple script :

...
void Update()
{
      if ( Input.touchesCount > 0 )
      {
            someGameObject.transform.position = Vector3.zero;
      }
}

And there’s no hiccup as expected. However, with some additional testing I noticed there was still a hiccup if I added a debug.log message like so :

...
void Update()
{
      if ( Input.touchesCount > 0 )
      {
           // would cause a slight hiccup on initial touch as well...
           Debug.Log("something");
      }
}

Any ideas? I’m curious about this but I won’t mind creating a dummy button that will process the first click and progress with the rest of the game smoothly…

Thanks!

2 Likes

I’m also seeing this happen. Testing on an old Kindle Fire.

Unfortunately I haven’t come across a solution other than making an unavoidable button to take the first hiccup. :frowning: :frowning:

Am I late? Well, you can trace this with “DeepProfile” in Profiler. Basiclly it could be ANYTHING because it’s not a single call, take a look then you will know what’s going on there.

Tips: In most case, it’s your Button.OnClick event invoke a slow function.
Tips2: You can’t really rely on those time displayed in DeepProfile mode since this mode have significant effect on that, so use this mode wisely.

1 Like

I am also having the same issue how did you solved this

Bump. 1st touch 12kb of GC and 200ms delay

Unity 2019.1 , just the first touch anywhere on the screen on Android causes 250ms of lag from EventSystem.Update(), tried disabling all of my canvases, nothing makes it better.

2 Likes

In my case the lag was caused by Mono.JIT. Building the Android player using IL2CPP fixed it for me.

1 Like

In my case, it was a call to DateTime.Now somewhere deep in the methods that was slow!
take a look at this:

I replaced the code with Time.time and it’s fixed now.

Mono build causes the lag. IL2CPP build fixed it for me as well. And I disabled the “Raycast Target” for the objects which doesn’t need it. This will reduce the EventSystem effort/Update.

1 Like