Beseitigt "mystery-consing" in dieser Common-Lisp-Funktion?

Diese Common-Lisp-Funktion, die einfach vier Ecken der Drahtgitterkanten einer Wand mit extrem einfacher Kindergarten-Arithmetik und ein paar "Case" -Tests berechnet, scheint für die dynamische Zuweisung von 196608 Bytes pro gerenderten Frame verantwortlich zu sein; Der Profiler der SBCL sagt mir, dass dies meine problematischste Funktion ist, soweit es sich lohnt. Um einen Überblick zu geben, woran ich gerade arbeite, handelt es sich um ein kleines First-Person-Dungeon-Crawler-Spiel. Ein Dungeon besteht aus genau 32x32 Zellen und jede Zelle hat 4 Wände. 32 * 32 * 4 * x = 196608, und so entpuppt sich x als 48, was zufällig 4 * 12 ist (4 Wände * 12 Schwimmer pro Wand? Vielleicht nicht).

Nun kann ich dieses Performance-Problem leicht beheben, indem ich OpenGL-Display-Listen im Gameplay-Modus verwende, und ich nehme an, dass ich das tun werde. Trotzdem, 1) Ich optimiere generell nicht vorzeitig, und noch wichtiger: 2) Ich mag es immer noch nicht, bestimmte lästige Jucke wie diese unzerkratzt zu lassen, und ich frage mich, was ich sonst hätte tun können. Meine Funktion wie sie ist, ist wie folgt:

Um ein paar Dinge zusammenzufassen, habe ich versucht, das zu beheben:

1. Erledigen Sie ein "deklarieren", um für "Geschwindigkeit" bei 3 und alles andere bei 0 zu optimieren (sowohl in dieser Funktion als auch in der einzigen Funktion, die es aufruft). Seltsamerweise hat der Profiler diese Funktion etwas weniger berüchtigt gemeldet ... aber er konzedierte immer noch. Ich ziele auf Null-Consing. Arithmetik sollte keine Nachteile haben.

2. Dann dachte ich, "Werte" könnten dies tun. Vielleicht, dachte ich, ist es innerlich nur etwas wie die Funktion 'liste', die ohne Zweifel (der einzige Zweck der 'Listen'-Funktion im Universum) konsektiert. Was habe ich getan, um dies zu mildern? Nur zum Zweck des Experiments habe ich die Datei modifiziert, um ein einzelnes wall-vertex-buffer globales Array zu erstellen, das 12 Elementen vom Typ float entspricht und sowohl diese Funktion modifiziert, als auch die aufrufende Funktion um nach dem Aufruf dieser Funktion von ihr zu lesen (so würde sie ständig eine einzige Menge von 12 Schwimmern aktualisieren, die an derselben Stelle im Speicher gehalten werden, anstatt etwas zuzuordnen). Seltsamerweise hat dies NICHT verhindert, dass diese Funktion zu einer Schweinerei wurde! Also ... war das "case"? Ich finde es interessant, dass, wie bereits erwähnt, diese Mystery-Nummer 48 war. 48 = 4 * 12, vielleicht diese 4 Case-Tests mal 12 Floats pro "Wert" -Ruf. Oder, das könnte ein Zufall sein, mit 48 Bytes was anderes bedeutet (da ein float NICHT 1 Byte ist, vermute ich, ist -is etwas anderes). Dies scheint signifikant zu sein, aber ich kann mir nicht vorstellen, was mein nächster Ansatz sein sollte.

3. Versuchte, "case" durch ein "cond" -Äquivalent zu ersetzen, indem man an dieser Stelle nur nach Strohhalmen griff, tat auch nichts.

Wo also könnte das "Mystery Consing" dieser Funktion herkommen? Wie würden Sie erfahrenere Lisp-Programmierer diesen kniffligen Scherz eines Problems angehen?

(EDIT) für @FaheemMitha, ist die Funktion, die die Funktion calculate-wallpoints benutzt; diese lästige Funktion wurde später mit (Deklarieren (Inline-Berechnung-Wand-Punkte)) kurz vor der Berechnung-Wand-Punkte-Definition inline:

nil)