W grę wchodzą (co najmniej) dwa czynniki. Procesory graficzne mogą korzystać z bufora wierzchołków po transformacji podczas renderowania indeksowanych operacji podstawowych. Rozmiar tej pamięci podręcznej jest różny i jest wykorzystywany podczas pojedynczego połączenia losującego (o ile wiem, nie w wielu połączeniach), więc nie ma znaczenia, jak często zmieniasz dane bufora w tym kontekście).
Jeśli zorganizować swoje dane, aby skorzystać z tej pamięci podręcznej (algorytm przykładem jest tutaj ), można zobaczyć poprawę wydajności. Jednak ta organizacja ma więcej wspólnego z porządkowaniem indeksów, tak aby każdy potrójny indeks ponownie używał jak największej liczby ostatnio widzianych wierzchołków. Prawdopodobnie ma to niewielki wpływ na konkretny scenariusz, chyba że trójkąty, za pośrednictwem bufora indeksu, są również losowo rozrzucone w buforze ... w takim przypadku prawdopodobnie często wysadzasz pamięć podręczną. W twoim pytaniu nie było dla mnie jasne, czy tak było, więc pomyślałem, że warto o tym wspomnieć.
Bardziej prawdopodobnym problemem może być to, że procesory graficzne również buforują dostęp do pamięci podręcznej danych wierzchołków podczas losowania. Rozmiar tej pamięci podręcznej jest również dość niewiarygodny i można sobie wyobrazić, że można uzyskać wysoką częstotliwość braków w tej pamięci podręcznej na poszczególnych rdzeniach przetwarzających te indeksy na bardzo słabo zlokalizowane dane wierzchołków.
Jeśli chodzi o to, czy nie, spowoduje to wystarczająco dużo problemów z wydajnością, aby być czerwoną flagą w twojej aplikacji, aw szczególności (to brzmi jak) ponowne zaprojektowanie algorytmu w celu lepszego uporządkowania danych kosztem czytelności algorytmu ... to nie jest coś, na co mogę odpowiedzieć, będziesz musiał profilować niektóre scenariusze i zobaczyć.
Osobiście popełniłbym błąd po stronie czytelnego, łatwego do utrzymania kodu, ponieważ uważam, że brakująca pamięć podręczna, którą spowodujesz, nie będzie wystarczająco znacząca, aby użytkownicy mogli to zauważyć.