Quick3D Benchmark becomes CPU bound on RHI-based 3D rendering path

We experience a 4x drop in FPS when running with RHI and having 1000 objects on screen, with the GPU far from being maxed out (with direct OpenGL the rendering is GPU bound with that many objects, meaning one should see a 99% or so utilization, this is not the case with the RHI-based rendering path)

A quick profiling session reveals many things that can be optimized. The amount of QByteArray, QString, comparison, hash, etc. operations are suprisingly high on the "hot" code paths, meaning code that is executed for every object in every frame.

Above are two screenshots with some interesting parts highlighted from a release build of dev. (from VTune, the VS profiler was not very useful unfortunately)

It is essential to get the cost of some of these operations down, first and foremost the QString/QByteArray ones should be eliminated somehow. For example, the RHI path does this for every image on the material for each object in setRhiMaterialProperties:

That append gets pretty expensive when it needs to realloc, presumably? (the 19 ms is a number accumulated from a lot of frames with 1000 objects each, so it may not be that expensive, but the time spent on this whole function should ideally be 0)

When it comes to hash tables, hash functions, comparisons, etc. those should be investigated as well, while they cannot be eliminated some of them could likely be made more lightweight. Then there is plenty of interesting things in the non-highlighted, lower sections as well (bindingForTexture? QByteArray::number()? etc.)