Bad Performance

Posts that don't fit into other categories.
x34
Posts: 4
Joined: Tue Nov 28, 2017 11:31 pm

Re: Bad Performance

Postby x34 » Fri Dec 01, 2017 3:14 pm

William wrote:OP - have you had chance to test these changes or to test with Android 8?

Thanks,
William

Hello William,

thank you for your patience. After I updated my IDE, it shot down Git and I didn't wanted to continue making fundamental changes before fixing that.

First things first, Android 8 Oreo has a marketshare of 0.3 % right now (even below Android 2). Devices with Android 8 are rather rare. Android 5 (2014) and 6 (2015) with 50 % marketshare is therefore used as a base reference by now and probably for the next months - I can't give an ETA for that.

I have compared 3.2.5 and 3.2.4 with one another and measured the same application in two different scenarios:
- release mode (this is where the VM optimizer kicks in)
- debug mode (profiler - not recording)

Long story short:
- Debug mode: 3.2.5 has a 10 % increased performance (270+- to 300+ ms)
- Release mode: 3.2.5 has a 25 % increased performance (30+- to 40+ ms and 15 to 20 ms)
- The AABB+Vector allocation count reduced from 27,000 allocations in 36 seconds (750 a/s) to 7,000 in 45 seconds (169 a/s) total.

It wasn't very easy to measure the performance reliably and it took a while to get consistent results with different configurations. I believe this is due to nature of the big.little CPU architecture that switches to a more powerful CPU when the load increases and vice versa. At the end I used a sleep time of 100 and 1 ms in between.
Please note that I forced dyn4j to update every cycle by calling world.update(1000);.

Here are some screenshots from the cpu and memory profiler (debug mode - recording).
If you look closely at the very top of this flame chart, you are going to notice that Vector (o.d.g.V) and AABB (o.d.g.A) "<init>" is gone.
flame_old.png
flame_old.png (52.46 KiB) Viewed 1377 times

flame_new.png
flame_new.png (55.7 KiB) Viewed 1377 times

x34
Posts: 4
Joined: Tue Nov 28, 2017 11:31 pm

Re: Bad Performance

Postby x34 » Fri Dec 01, 2017 3:18 pm

This is the memory profiler output.
memory_old.png
memory_old.png (117.04 KiB) Viewed 1377 times

memory_new.png
memory_new.png (114.92 KiB) Viewed 1377 times
Last edited by x34 on Fri Dec 01, 2017 3:28 pm, edited 1 time in total.

x34
Posts: 4
Joined: Tue Nov 28, 2017 11:31 pm

Re: Bad Performance

Postby x34 » Fri Dec 01, 2017 3:25 pm

And last, a small CPU output with execution times if you are interested. As I said isStatic takes 25 % of execution time. Also, 3.2.5 called a lot more methods this time, I do not know if this was just randomly.
cpu_old.png
cpu_old.png (79.1 KiB) Viewed 1377 times

cpu_new.png
cpu_new.png (83.92 KiB) Viewed 1377 times


With best regards

William
Site Admin
Posts: 378
Joined: Sat Feb 06, 2010 10:23 pm

Re: Bad Performance

Postby William » Sun Dec 17, 2017 4:51 pm

Thank you for the analysis and sorry for getting back to this late. I've made a few very small changes to see if the time in the isStatic method is due to the logic contained therein or due to the function calls and it not being natively compiled/inlined.

Can you give it a try when you get a chance?

x34 wrote:First things first, Android 8 Oreo has a marketshare of 0.3 % right now (even below Android 2). Devices with Android 8 are rather rare. Android 5 (2014) and 6 (2015) with 50 % marketshare is therefore used as a base reference by now and probably for the next months - I can't give an ETA for that.

Not a problem. I was just curious how much of a difference it will make.

x34 wrote:Also, 3.2.5 called a lot more methods this time, I do not know if this was just randomly.

If the methods were just AABB methods, then we could conclude it was due to the code changes made in 3.2.5. From the screenshots you provided, it seems more likely that these are showing up on the profiler now because they take a larger percentage of the execution time since the code change. Another possibility could be what methods the JIT compiler decided to compile and when.

Thanks,
William
Attachments
dyn4j-v3.2.5_rc2.jar
(371.48 KiB) Downloaded 44 times

x34
Posts: 4
Joined: Tue Nov 28, 2017 11:31 pm

Re: Bad Performance

Postby x34 » Mon Jan 08, 2018 2:00 pm

William wrote:Thanks,
William

Is your provided Jar the same code over at GitHub? Just noticed that Android Studio has major problems processing JDK9 you compiled this jar with.

Best Regards

William
Site Admin
Posts: 378
Joined: Sat Feb 06, 2010 10:23 pm

Re: Bad Performance

Postby William » Mon Jan 08, 2018 10:20 pm

Yes. The changes I made for rc2 are checked into the master branch in github.

x34 wrote:Android Studio has major problems processing JDK9 you compiled this jar with.

That's good to know - I will take a look at this.

William

Iona
Posts: 1
Joined: Mon Jan 29, 2018 4:23 am

Re: Bad Performance

Postby Iona » Mon Jan 29, 2018 4:42 am

Hi, there))
Maybe it is a use-case that can be optimized in many ways but it is impossible to tell. Thank you for the analysis here ))!

William
Site Admin
Posts: 378
Joined: Sat Feb 06, 2010 10:23 pm

Re: Bad Performance

Postby William » Sat Mar 10, 2018 10:13 am

OP - any more feedback on this?

I'm looking to do a release soon.

William

William
Site Admin
Posts: 378
Joined: Sat Feb 06, 2010 10:23 pm

Re: Bad Performance

Postby William » Sat Apr 21, 2018 11:29 am

The performance improvements tested here were included in the 3.3.0 release.

Thanks,
William


Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest