Zwingend verwenden müsste ich es nicht denke ich. Wenns "nicht speicheroptimiert" läuft wird das System wohl noch fast genauso performant sein. Der angeblich 8x langsamere Speicherzugriff halte ich in dem Maße für ein Gerücht. Aber im Endeffekt muss man sich ja schließlich an die neue Design-Richtung von Siemens anpassen, ob man will oder nicht. Ich hab ein bisschen rumgespielt und einige Dinge doch halbwegs mit dem Variant-Datentyp retten können und andere Dinge widerum neu geordnet. Das bedeutet beispielsweise statt gleiche Daten auf mehrere DBs zu verteilen und diese dynamisch hin und herzukopieren verwende ich nun Arrays von UDT-Strukturen in einem DB. Naja, mal schauen wie es sich in der Praxis bewährt.
Ich bin weder Compiler-, noch CPU-Entwickler und vielleicht habe ich ja auch Unrecht, aber mal ganz ehrlich, ich kaufe Siemens nicht wiklich ab, dass diese Änderungen nur aufgrund von Performance-Optimierungen getroffen wurden, mal abgesehen davon, dass es bei einer SPS deutlich mehr um Stabilität und Zuverlässigkeit geht, als um Performance. Hier geht es doch eindeutig darum, die Programmierung in eine bestimmte, "einfachere" Richtung zu lenken. Variablen und Symbole sind doch eh nur Hilfskonstrukte, hinter denen immer eine Adresse steckt. Wer sich in hardwarenahem C auskennt weiß, dass man für performante Systeme nur mit Adressen und Zeiger hantiert. Unnötige Variabeln im Speicher sind hier ein absolutes no-go. Ok, dafür sind die Programme nur für den Programmierer verständlich, aber die Zeiger- und Adressenarithmetik in der SPS-Welt hatte doch eh nie solche Dimensionen angenommen und war deutlich weniger komplex. Daher unnötig dort so restriktiv einzugreifen.
