Aug 31 2015, 9:53 am
|
|
Lummox JR
  |
Yes, Timsort should be trivial to change there because I've already implemented it.
|
All testers once again used Chrome, though I didn't check to see if FPS is as bad on other browsers... but I'm assuming it is based on the past cases. FPS also drops considerably during heavy animation instances, such as PvE where there's multiple mobs and spell effects.
Tester #5 - http://puu.sh/jVkZZ/9ba287f696.png Movement: 9-14FPS Idle: 13-19FPS Tester #6 - http://puu.sh/jVl2l/0c558b9558.png Movement: 8-12FPS Idle: 11-14FPS Tester #7 - http://puu.sh/jVl6F/79a745671f.png Movement: 18FPS Idle: 32FPS Tester #8 - http://puu.sh/jVlcR/17674f3e1e.jpg Movement: 58FPS Idle: 60FPS Tester #9 - http://puu.sh/jVluH/1968e45cdd.png Movement: 10-15FPS Idle: 20-25FPS | |
Interesting results, although I think tester #6 is a write-off. Windows 10 with 2 GB of RAM? Good gads.
| |
My machine idles at 44fps, but during movement, I drop to around 32fps. I didn't bother with the other machines, because I was able to pin the issue down to specific javascript functions.
I took the liberty of doing some profiling. I'll PM you a copy of the profiling data from chrome during one of the heavy phases. It's pointing mostly to unoptimized methods due to several functions constantly trying to re-optimize due to "optimized too many times" errors: https://groups.google.com/forum/#!topic/v8-users/_oZ4fUSitRY There are also a lot of optimization warnings here and there: https://github.com/petkaantonov/bluebird/wiki/ Optimization-killers The good news is that this is definitely a scripting issue, which means with some work, it should be doable to fix. | |
Very interesting! (I'm also curious how you managed to profile the code. I haven't been able to find good info on that.)
What I hope is that a number of the functions involved are something that I can fix. Because the webclient is compiled from Dart in Dart2js, I don't have direct control over most of the JS code. But I suspect there are a lot of functions where this isn't a big deal. | |
Chrome comes with a code inspector. It's really great.
https://developer.chrome.com/devtools/docs/cpu-profiling | |
I think I found one of the big culprits: AtomInfo.animating() had a call to List.firstWhere() that I think was freaking it out. If I'm reading my new results right, that's no longer the case in my modified code.
Combing through this JSON is kind of brutal so it might be hard to identify more cases (plus some are on common funtions that are hard to weed out, like I notice JsLinkedHashMap.$index has that issue), but I'll see what else I can find if any. | |
I went ahead and released without trying Timsort, the main reasons being 1) I'm not convinced my Timsort implementation wouldn't be more of the same issue, 2) sorting seems to be only a small factor, and 3) I'd like to reduce the number of variables while tracking improvements.
508.1299 is the new public release, but the webclient is still considered a beta feature and will continue to be worked on in the upcoming 509 beta builds. | |
With the new version, immediately after firing game up:
Movement: 40FPS Idle: 60FPS After a couple minutes of combat / playtesting: Movement: 15FPS Idle: 20FPS Specs: http://i.imgur.com/5cIY7LL.png | |
How does that compare to your earlier tests on the same machine?
| |
I think this was on the same machine: http://www.byond.com/forum/?post=1917533#comment16358148
The degradation over time is new to me though. Did FPS return to 40/60 when you moved back to the spawn without any PvE, or did it stay at 15/20 regardless? The testers also noticed a FPS drop during PvE, but I assumed this was natural since there's more going on in the screen. FPS was better in areas with less, such as small sized interior where there's a fair amount of black space on-screen. | |
I have a hunch that maybe some atoms are staying alive longer than intended, and that could be causing the degradation. I'll have to run some tests myself.
If anyone else wants to also run some profiling, having more results to comb through would be a big help. I'm most interested in routines that aren't optimizing well, and what I can do to fix that. | |
Here's a profile snapshot of the latest [509.1301] BYOND release: (It's raw JSON but if you open it with the chrome profiler it'll arrange it in something more legible)
http://puu.sh/kl1dH/e16bd6725b.cpuprofile Performance seems to be increasing with the passing releases but it's still not anywhere we'd like it to be. | |
Thanks for that profile data. It was quite useful. One of the major things it pointed out to me was that MapView.SetVisBits() was taking way, way too long and most of the time was not accounted for by function calls as I would have expected. Upon reviewing the JavaScript, it turns out that Dart2js was compiling in quite a few wholly unnecessary checks on array bounds and other such stuff. I found an option to turn all that off, and I expect the next release will improve matters quite a lot. It's impossible to quantify that at this time, but I have high hopes.
| |
In the latest version there's a big improvement, with my FPS now at 20-25, after originally being at 6-10. Still not up to par with DS, mind, but definitely a step in the right direction.
| |
Glad to hear it!
| |
I forgot to add this, but if you can get new profiler data on the updated version, that'd be terrific. The more data the better!
| |
http://puu.sh/kxLek/cdf9259675.cpuprofile
CPU profile for build 509.1303. Let me know if anything else needs clarifying. | |
How's this going?
| |
I worked a little on the data I got from 1303, but please keep the reports coming. More profile data is always good.
| |