Hello
@bioan
Some time ago, I turned to similar thoughts about separating Graphic3d_ArrayOfPrimitives on parts to improve performance. However, looking inside I started to relate to this class as to something entire. Finally, I did not decompose it and solve performance troubles in another way. There are some reasons of it. The first one is that inside this class uses Graphic3d_AttribBuffer that is similar in some extent to some standard container. Graphic3d_ArrayOfPrimitives is the fundamental class used in all primitives. So, it looks that we may rely on. Another thought, that if we add additional conditionals in such internal processing, it also may decrease speed of processing it.
Anyway, it is the field of experiments if we found the bottleneck exactly here, as you proposed).
In my experiments, I did investigations in more upper level. First, I switched off the selection recompute during animation; it’s not really need, is it? It might be helpful to investigate how many times this container data is preparing (in case of topology shape it may eat more time that updating array of primitives). Also, if you animate something, you may during animation minimize number of data animated, sure if it’s possible in your algorithm. It’s also might be helpful to set some timer delay (if you’re processing the mouse) and decrease number of compute calling (there might be many-many updates but the eye do not see them).
So, the proposal here, to investigate firstly your data preparing on more upper level and only if there are no loss of time there, try to look inside Graphic3d_ArrayOfPrimitives.
If you nevertheless find that any other things do not waste time in your application and the solution is to manage somehow this class, it would be very, very interesting if you share results of your investigations.
Cheers, Natalia
