search

850176300 / dotween

Automatically exported from code.google.com/p/dotween
0 stars 0 forks source link

CPU spikes in DOTweenComponent.Update #29

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
>> What steps will reproduce the problem?

1. Create two bezier path managers.
2. Add 5 gameobjects to each path with the bezier move behavior (10 followers 
total, 5 on each path)
3. Play the Unity scene.
4. Observe there are very high CPU spikes in the function 
DOTweenComponent.Update() on PC and Android builds that range from 88ms to 
117ms (see attached screenshot).

>> What is the expected output? What do you see instead?

The expected output is no CPU spikes during the scenario described above.

>> What version of the product are you using? On what operating system?

Tested on Unity 5.0.0f4 with Windows 7. DOTween library came in binary form 
with the Simple Way Point system asset (which uses DOTween of course). The 
reported DOTween version by this asset is 1.0.225 [Release Build]

>> Please provide any additional information below.

I have reported this issue in the SWS forum as well for visibility. Here is the 
link: http://www.rebound-games.com/forum/index.php?topic=172.0

Original issue reported on code.google.com by gustavo....@gmail.com on 8 Mar 2015 at 10:27

Attachments:

GoogleCodeExporter commented 9 years ago 
Ok, so it seems the performance issues are due to Debug.Log calls lingering in 
the code. This should be easy to fix:

DOTween/Plugins/Core/PathCore/Path.cs:66
DOTween/Plugins/Core/PathCore/Path.cs:55

Original comment by gustavo....@gmail.com on 8 Mar 2015 at 11:12

GoogleCodeExporter commented 9 years ago 
Hi Gustavo,

I apologize, I created those logs recently while testing stuff, but leaving 
them around in a release build was completely idiotic of me. Grab this version 
in the meantime which fixes it, and I'll release it publicly later, with a few 
more additions I'm working on.

Original comment by daniele....@gmail.com on 8 Mar 2015 at 3:42

Attachments:

GoogleCodeExporter commented 9 years ago 
Good day Daniele,

Thanks for the quick response. I have tested the fix and the CPU spikes are 
greatly reduced but they are not completely gone. With the same setup described 
above the CPU spikes have been reduced to around 31ms on the PC build, on 
Android the spikes last around 87ms. I'm attaching a screenshot of the PC build 
Unity profiler.

I think there is still some issue lingering there. Not sure if this helps but 
the problem seems to happen when an object finishes a path (each object is set 
to Loop the path).

Original comment by gustavo....@gmail.com on 8 Mar 2015 at 7:19

Attachments:

GoogleCodeExporter commented 9 years ago 
Ok, I have confirmed the issue happens when an object finishes traveling the 
path and it returns to the beginning again. Unfortunately I can't share you a 
project with my scene setup but I created a simple one to describe you the 
problem. See attached screenshot, let me know if I can help further.

Original comment by gustavo....@gmail.com on 8 Mar 2015 at 7:47

Attachments:

GoogleCodeExporter commented 9 years ago 
Good day to you Gustavo, and thanks for the detailed reports.

Could you share with me another screenshot, but with the Profiler set to "deep 
profile", and its hierarchy expanded to see what internal 
DOTweenComponent.Update part is using most of the resources during the spike?

Also, are you moving a rigidbody by any chance (in which case the spike might 
be caused by Unity translating it over a wider distance during restart, and 
thus needing more physics calculations)?

Thanks!

Original comment by daniele....@gmail.com on 8 Mar 2015 at 8:33

GoogleCodeExporter commented 9 years ago

Original comment by daniele....@gmail.com on 8 Mar 2015 at 8:33

GoogleCodeExporter commented 9 years ago 
Hi Daniele,

Find attached a screenshot with the Deep Profile option enabled. From the data 
it seems most of the time is spent in CatmullRomDecoder.GetPoint(), the 
function CatmullRomDecoder.SetWaypointsLength() calls it so many times it just 
doesn't seem right (51170 times). Another red flag is 
CatmullRomDecoder.SetTimeToLengthTable() calling it 731 times.

On the test scene each path follower has a non-static collider and a rigidbody 
indeed, however I have no evidence this is the cause of the performance problem.

Regards,
Gus

Original comment by gustavo....@gmail.com on 9 Mar 2015 at 1:30

Attachments:

GoogleCodeExporter commented 9 years ago 
Hiya,

the only reason why GetPoint is called so many times when the tween starts 
(both when called by SetWaypointsLength and SetTimeToLengthTable) is that the 
path subdivisions-x-segment are set to some massively high value. In your case, 
with 8 waypoints, that would be a value of 6396, while the recommended value is 
5, or 10 if you want high resolution. Anything more than that is useless.

Are you setting the path subdivisions manually or is SWS setting them 
automatically (in which case I'll contact Baroni)?

Original comment by daniele....@gmail.com on 9 Mar 2015 at 11:02

GoogleCodeExporter commented 9 years ago 
P.S. I investigated around your report more, and while the previous issue I 
mentioned remains, I also optimized some internal calls. This update will call 
GetPoint a lot less times (but still too many, so the previous issues remains).

Original comment by daniele....@gmail.com on 9 Mar 2015 at 11:22

Attachments:

GoogleCodeExporter commented 9 years ago 
P.P.S. I contacted Baroni in the meantime to check if the path's resolution is 
set automatically by SWS, and eventually fix it on his side.

Original comment by daniele....@gmail.com on 9 Mar 2015 at 12:18

GoogleCodeExporter commented 9 years ago 
Hi Daniele,

I found the code in SWS that starts the tween and sets the resolution (default 
to 10):

tween = transform.DOPath(wpPos, originSpeed, pathType, pathMode)
                             .SetAs(parms)
                             .SetOptions(false, lockPosition, lockRotation)
                             .SetLookAt(lookAhead);

I inspected the API and the resolution is 10 if no argument is given for that 
parameter. I tried different values from 5 to 0 and the CPU spikes decreased 
dramatically. Zero gave me an almost unnoticeable CPU spike (not gone thought).

tween = transform.DOPath(wpPos, originSpeed, pathType, pathMode, 0)
                             .SetAs(parms)
                             .SetOptions(false, lockPosition, lockRotation)
                             .SetLookAt(lookAhead);

Attached is the screenshot when 0 resolution is used. 
CatmullRomDecoder.GetPoint() is still being called plenty of times though (5180 
+74). I noticed setting the resolution to 0 didn't change change the quality of 
the Tween animations, this suggests possibly there is something wrong in the 
way the resolution is handled in the code?

Regards,
Gus

Original comment by gustavo....@gmail.com on 10 Mar 2015 at 5:51

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi again Daniele,

I have good news! I used the DOTween version 1.0.280 attached above by you and 
by setting the resolution to zero the issue is completely gone, no CPU spikes 
at all and my 10 tweens on two different paths are silky smooth. The 
DOTweenComponent.Update() takes from 0.8ms to 0.23ms on my PC and takes 0.33ms 
to 0.63ms on my target Android device. Thanks a lot for your help :)

I'm looking forward for the public update.

Regards,
Gus

Original comment by gustavo....@gmail.com on 10 Mar 2015 at 6:10

GoogleCodeExporter commented 9 years ago 
Great! :) Baroni told me he fixed his side of the issue already, so this should 
be up very quickly

Original comment by daniele....@gmail.com on 11 Mar 2015 at 10:35