As I said above, I couldn’t reproduce the slowdown when the line isn’t commented versus when it is.
This is something I’d like to see, a real PG (or better: several PGs) where the framerate is significantly different in both cases => it’s not only me, other people in the team will also run the tests, to get a wider range of results.
Performance snapshot figures are not sufficient to justify code modification. They’re great for pointing out code that might be a bottleneck / paint point / in need of improvement (as you’ve done in this thread for this._totalVertices.addCount
), but the next step is to test what happens when the code is updated to fix / improve what was found in the first step.
Don’t get me wrong: it’s obvious that this._totalVertices
takes time, and if it were possible to simply delete the line, there’d be no discussion and we’d do it! But that’s not possible, the only thing we can do is something like:
if (!this.disableTotalVerticesPerfCounter) {
this._totalVertices.addCount(mesh.getTotalVertices(), false) ;
}
So, what should be tested are PGs when:
- A: using existing code
- B: using the code with the if condition and
disableTotalVerticesPerfCounter=false
.
- C: using the code with the if condition and
disableTotalVerticesPerfCounter=true
.
Then compare the results.
C will probably be equal to or faster than A (still, we need numbers, because if we can’t prove that it’s faster in some cases, there’s no point in making the change).
The concern is A versus B, B being what we’ll get by default if we make the change. If B is significantly slower than A, we probably won’t make the change, because that’s what people will experience with the default configuration.
We need to be very careful because this code is a hot path, it’s called at every frame and for every mesh, so we need to be very sure that we’re not hurting performance when we make changes.
I’ll try to do some testing on my own, but I’m very busy at the moment, so I can’t commit to a timetable.
[EDIT] I should answer this one:
I meant real word scenarios than I and others in the team can run and test for themselves 