Die schnellste Möglichkeit, etwas darzustellen sind VBO und State changes, sowie Bindings in eine Displayliste zu packen.
Das VBO ist die einfachste Art Daten im VRam einzulagern und je nach Bedarf Teile oder das ganze VBO zu nutzen.
Displaylisten verpacken dann die ganzen Befehlsaufrufe und diese liegen dann ebenfalls im VRam und noch dazu vom Treiber optimiert und benötigen keine Synchronisierung von CPU und GPU(für die einzelnen Befehle in der DL).

Eine von ATI empfohlene Zeichenabfolge wäre wie folgt.
-erstelle VBO(Vertice,Texcoord,Color,...)
-erstelle Shader
-lade Texturen
-erstelle Display List für das zeichnen von Vertice
-erstelle Display List für das zeichnen von dem ganzen VBO Daten mit Texturen und Shader

Forward Rendering:
First Pass(Z-Pass): rufe 1. Display List auf
Second Pass(Draw): rufe 2. Display List auf
Third Pass(Posteffects): viele bunte Shader wie Blur, Bloom, HDR, Colorbleeding, ...

In der Praxis wird der Unterschied, zwischen mit Display List und ohne, kaum spürbar sein, da der Botleneck sehr stark in andere Bereiche gedrängt wird.
Physik, Ki, Füllrate, schlechte SceneGraph Konzepte und schlechte Synchronisierung der Threads sind da viel Ausschlaggebender.

Wenn es um Triangle geht, dann sollte man lieber mehr nehmen, statt zu wenig.
Der maximale Triangledurchsatz ist heute schwer zu erreichen, weit vorher meldet sich die Füllrate bzw. der VRam zu Wort.
Ausser man schreibt Programme die keine Texturen und Shader benutzen ... .

Mein Modelloader benötigt für das Testmodel ~7ms unter Windows Vista/XP bis es von der Festplatte, über den Arbeitsspeicher, in den VRam geschickt wird und unter Linux Fedora 9/10 dauert es ~6ms.
Ich hab das mehrmals ausprobiert und der Grund für den Unterschied ist auch recht einfach zu erklären, da Linux die Hardware wesentlich flacher anbindet und somit der Weg von Software bis zur Hardware weniger Code durchläuft.
Windows hat Hard/Software-Zertifikate für einzelne User, mehrere Treiberebenen(Kernalspace,Userspace,Systemspace,...) und überwachungsinstanzen(je nachdem was es für Hardware ist).
Wenn man dann GUI in OpenGL programmiert, dann kann man das gleiche Problem wiederfinden.
Des so mehr Klassen voneinander abgeleitet sind und untereinander Kommunizieren müssen, des so langsamer wird die ganze GUI.
Auch wenn der Compiler abgeleitete Klassen stark optimiert sind troztdem für jede Ableitung mal ein Push,Pop, copy(wenn keine Referenzen/Pointer verwendet werden) pro Methode dabei(wieso das gcc und fpc nicht zu einen einzigen codeblock zusammenpackt hab ich bisher nicht rausbekommen).
Was dann richtig zu buche schlägt sind dann übertriebende Eventsysteme bzw. Widgets, wenn es der Programmierer mal wieder zu gut meinte und das volle OO Konzept durchzieht und vergisst, dass er eine GUI schreibt die >60 mal die Sekunde durchlaufen muss und nicht 1 oder 2 mal die Sekunde(wenn es hoch kommt). Was dann mit jedem Methodenaufruf, State change und Logik Prüfung starken Einfluss auf die Laufzeit ausübt.
Wenn wer mal eine nicht gut Konzipierte GUI sehen will, der muss mal World of Warcraft probieren, da sind die Performance unterschiede von mit GUI und ohne so extrem, dass es bei meiner gf8800 mal gut 20-30% FPS unterschied macht.
Zum einen verliert die GUI viel zeit mit dem Scriptinterface(LUA), welches Zeichenfunktionen und tiefer gehende Funktion wrapped und zu allem übel auch noch XML als Konfigurationsdatein anbietet.
Dann drückt die Netzwerkkommunikation ganz stark, unter linux kann ich jeden Socketaufruf in der Shell von wine sehen, da fragt man sich teilweise, was die geraucht haben, als man die Item Validierung in die GUI implementiert hat.

Das meiste Optimierungspotenzial hat in der Regel der Codeaufbau, sowie die Logik und weniger eine einzelne Funktion/Methode/Codeblock.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004