Respuestas:
Hay (al menos) dos factores en juego aquí. Las GPU pueden utilizar una memoria caché de vértices posterior a la transformación cuando se representan primitivas indexadas. El tamaño de este caché varía, y se utiliza durante una llamada de extracción individual (no a través de varias llamadas, por lo que sé, por lo que no importa con qué frecuencia cambie los datos del búfer en ese contexto).
Si organiza sus datos para aprovechar esta caché (un algoritmo de ejemplo está aquí ), puede ver mejoras de rendimiento. Sin embargo, esta organización tiene más que ver con ordenar sus índices para que cada índice triple reutilice tantos vértices vistos recientemente como sea posible. Probablemente tenga poca relación con su escenario específico, a menos que sus triángulos, a través de su búfer de índice, también estén dispersos aleatoriamente en el búfer ... en cuyo caso probablemente esté volando el caché a menudo. No me quedó claro en su pregunta si este era o no el caso, así que pensé que valía la pena mencionarlo.
Lo que es más probable que sea un problema es que las GPU también tienen acceso a la memoria caché a los datos de vértice durante un sorteo. El tamaño de ese caché también es bastante poco confiable y es concebible que pueda obtener una alta frecuencia de fallas en ese caché en los núcleos individuales que procesan esos índices en datos de vértices muy mal localizados.
En cuanto a si eso causará o no un problema de rendimiento suficiente como para ser una señal de alerta en su aplicación, y en particular (parece) reestructurar su algoritmo para organizar mejor los datos a expensas de la legibilidad del algoritmo ... eso no es algo que pueda responder, tendrá que perfilar algunos escenarios y ver.
Sin embargo, personalmente me equivocaría con el código legible y mantenible, ya que creo que cualquier caché que falte que va a causar no será lo suficientemente significativo como para que los usuarios lo noten.