Some performance questions

I’m starting to have performance issues in a rather small project, and have a couple of questions.

  1. Am I correct in assuming that draw calls is related to the number of meshes inside an entity? (One draw call per mesh instance per entity), and so reducing the number of materials per entity will reduce the draw calls? I build up a map out of lots of small tiles, and some of the tiles have multiple materials. There are very few polies, but I think there will be a lot of draw calls, some of which I could probably reduce.

  2. What is the performance impact of setting uniforms inside a shader? I’m updating 3 floats every frame inside a post effect, and it seems to be making more of a difference then I would like. These floats aren’t changing the number of samples or anything I would associate with performance. The post effect does speed-streaks dependant on the x, y, and z speed of the player. I haven’t seen anything that would allow me to pass in a Vec3)

  3. Would using entity.clone() be faster than creating a new entity and adding components to it? I suspect it would be, but was wondering if you had any metrics on this rather than my “gut feel.” Actually, I haven’t got to this part of the project yet, but will very soon…

Drat, now that I test it again it’s running fine. Maybe having the chrome dev tools open slows things down. Oh well, my questions still stand.

Do you do this at runtime or just at the beginning of the app? If runtime, it be best to use entity pools over destroying/creating new entities especially if you do a lot of them.

Well I reduced the number of materials and it’s running better. Fewer textures to load as well, so it’s really a win-win.

@yaustar:
I planned to do it at runtime. However, in testing it was causing stuttering. Profiling says that its in the “add component” call, so out goes the easy solution, in comes the harder one.

Doing pools is an interesting one in this case, as it’s a procedurally generated environment. There’s a draw cap, so I know there will only be 70 tiles on screen, but I don’t know the composition of those tiles, and having 70 tiles of each type permanently in-scene will likely occupy a fair bit of RAM. Of course, the probability the map needing 70 of a single tile is very low.
I think I’ll try clone first, as that has no complications associated with it (aside from perhaps still being too slow), then try a dynamic-sized pool approach.