Data Query is Slow

[RobertBColton]

Discovered this while benchmarking the room clip with Rusky. Basically, accessing proto data through the models we provide is pretty damn slow, even in release mode. While this may be ok for some editors and reflection based views, it's particularly problematic for performance-critical views like the room editor.

One area I tested was caching of the descriptor and reflector used in the proto model. This cut field access for the x property of 100,000 instances from 13,000~ microseconds down to about 6,000~ microseconds.

https://github.com/enigma-dev/RadialGM/blob/faff910d6398ab2660f45c512450f48d45b47099/Models/MessageModel.cpp#L99

I have not yet been able to determine from the documentation whether it would be ok for us to do this all the time. https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.message#Reflection

There are also other potential avenues for optimizing all of this, including avoidance of QVariant for data access. One way to do so would be to simply grab and use the protobuf directly in the room painting, rather than access the data through the model.

[fundies]

13000 micro seconds is fast enough :/. The room editor only updates on changes we're not trying to draw it 60x/sec

[JoshDreamland]

It's fast enough... as long as we're caching this data somewhere else for things like animations. And we're going to want animations.

It's telling if we're saturating a core rendering something at normal game speeds. I think the problem is the reflection; even proto caches data, normally.

To fundies' point, the data won't update all that often. We can probably get away with a complete-destructive re-cache on update (throwing the entire cache away and building anew). But I don't think we have to. I think if you just key the fields you want by the rows they came from, you'll be fine, and we can update the model at the monitor's refresh rate with no issue (which we'll need to avoid pegging a core and lagging while someone is dragging a sprite on a 240hz display).

This logic doesn't even have to be specific to the room editor, but for now, it probably should be. There's probably higher-priority work, but I wouldn't tell someone not to tackle a problem they're interested in.

[RobertBColton]

You guys are missing a very important thing about what I said, I isolated only the x property, but there are about 10 properties plus a sprite lookup by string to draw every instance. So in reality, just to query the data necessary to draw 100,000 instances, not to even draw them, probably takes about 13,000 * 10 or 130,000 microseconds or 1/10th of a second. And you're still both ignoring that caching of the descriptor and the reflector in the proto model cut it in half, which is a very good optimization!

[JoshDreamland]

Everything we were discussing stands after multiplying the time by five and dividing by two.

A 2x speedup is good, but it won't cut it. We'll need more caching if we mean to render animations.

[fundies]

we could make it faster by removing all functionality