Die Abstraktion reduziert naturgemäß die Übermittlung von Informationen sowohl an den Programmierer als auch an die unteren Ebenen des Systems (Compiler, Bibliotheken und Laufzeitsystem). Dies ermöglicht es den unteren Schichten im Allgemeinen zugunsten der Abstraktion anzunehmen, dass der Programmierer sich nicht mit einem nicht spezifizierten Verhalten befasst, was eine größere Flexibilität bei der Bereitstellung des spezifizierten Verhaltens bietet .
Ein Beispiel für einen potenziellen Nutzen dieses Aspekts "egal" ist das Datenlayout. In C (niedrige Abstraktion) ist der Compiler bei der Optimierung des Datenlayouts stärker eingeschränkt. Selbst wenn der Compiler (z. B. durch Profilinformationen) erkennen könnte, dass Optimierungen zur Vermeidung von Hot / Cold oder zur Vermeidung falscher Freigabe von Vorteil sind, wird im Allgemeinen verhindert, dass solche Optimierungen angewendet werden. (Es gibt eine gewisse Freiheit, "als ob" anzugeben, dh die Spezifikation abstrakter zu behandeln, aber das Ableiten aller möglichen Nebenwirkungen belastet den Compiler zusätzlich.)
Eine abstraktere Spezifikation ist auch robuster gegen Änderungen bei Kompromissen und Verwendungen. Die unteren Schichten sind weniger gezwungen, das Programm für neue Systemeigenschaften oder neue Verwendungen neu zu optimieren. Eine konkretere Spezifikation muss entweder von einem Programmierer neu geschrieben werden, oder die unteren Schichten müssen zusätzliche Anstrengungen unternehmen, um ein "als ob" -Verhalten zu gewährleisten.
Der leistungsbeeinträchtigende Aspekt der Informationsverstecke ist "kann nicht ausdrücken", was die unteren Ebenen normalerweise als "weiß nicht" behandeln. Dies bedeutet, dass die unteren Schichten Informationen, die für die Optimierung nützlich sind, von anderen Mitteln wie der typischen allgemeinen Verwendung, der gezielten Verwendung oder spezifischen Profilinformationen unterscheiden müssen.
Die Auswirkungen des Versteckens von Informationen wirken auch in die andere Richtung. Der Programmierer kann produktiver sein, indem er nicht jedes Detail berücksichtigen und spezifizieren muss, aber der Programmierer verfügt möglicherweise über weniger Informationen über die Auswirkungen von Entwurfsentscheidungen auf höherer Ebene.
Wenn Code hingegen spezifischer (weniger abstrakt) ist, können die unteren Schichten des Systems einfacher das tun, was ihnen gesagt wird, als ihnen gesagt wird. Wenn der Code für die gezielte Verwendung gut geschrieben ist, passt er gut zur gezielten Verwendung. Eine weniger abstrakte Sprache (oder ein Programmierparadigma) ermöglicht es dem Programmierer , die Implementierung durch detailliertes Design und durch die Verwendung von Informationen zu optimieren, die in einer bestimmten Sprache nicht einfach an die unteren Schichten übermittelt werden können.
Wie bereits erwähnt, sind weniger abstrakte Sprachen (oder Programmiertechniken) attraktiv, wenn zusätzliche Fähigkeiten und Anstrengungen des Programmierers zu lohnenden Ergebnissen führen können. Wenn mehr Aufwand und Fähigkeiten des Programmierers angewendet werden, sind die Ergebnisse in der Regel besser. Darüber hinaus wird ein Sprachsystem, das weniger für leistungskritische Anwendungen verwendet wird (stattdessen wird der Entwicklungsaufwand oder die Zuverlässigkeit betont - bei Grenzprüfungen und der Speicherbereinigung geht es nicht nur um die Produktivität des Programmierers, sondern auch um die Korrektheit. Durch die Verringerung der mentalen Belastung des Programmierers durch Abstraktion kann die Zuverlässigkeit verbessert werden.) wird weniger Druck haben, um die Leistung zu verbessern.
Die Spezifität widerspricht auch dem Prinzip, sich nicht zu wiederholen, da die Optimierung normalerweise durch Anpassen des Codes an eine bestimmte Verwendung möglich ist. Dies hat offensichtliche Auswirkungen auf die Zuverlässigkeit und den Programmieraufwand.
Die von einer Sprache bereitgestellten Abstraktionen können auch unerwünschte oder unnötige Arbeiten enthalten, ohne dass eine weniger schwere Abstraktion gewählt werden kann. Während unnötige Arbeit manchmal von den unteren Schichten entdeckt und entfernt werden kann (z. B. können Grenzprüfungen aus dem Körper einer Schleife extrahiert und in einigen Fällen vollständig entfernt werden), erfordert die Feststellung, dass dies eine gültige Optimierung ist, mehr "Geschick und Aufwand" durch der Compiler.
Das Alter und die Popularität der Sprache sind ebenfalls bemerkenswerte Faktoren sowohl für die Verfügbarkeit qualifizierter Programmierer als auch für die Qualität der unteren Schichten des Systems (einschließlich ausgereifter Bibliotheken und Codebeispiele).
Ein weiterer Konfliktfaktor bei solchen Vergleichen ist der etwas orthogonale Unterschied zwischen der Kompilierung vor der Zeit und der Justierung in der Zeit. Während die Just-in-Time-Kompilierung Profilinformationen (die sich nicht auf den Programmierer verlassen müssen, um Profilläufe bereitzustellen) und die systemspezifische Optimierung (eine vorzeitige Kompilierung kann auf eine breitere Kompatibilität abzielen) leichter nutzen kann, wird der Aufwand für aggressive Optimierung als berücksichtigt Teil der Laufzeitleistung. JIT-Ergebnisse können zwischengespeichert werden, wodurch der Overhead für häufig verwendeten Code reduziert wird. (Die Alternative der binären Neuoptimierung kann einige Vorteile der JIT-Kompilierung bieten, aber herkömmliche binäre Verteilungsformate lassen die meisten Quellcodeinformationen fallen und zwingen das System möglicherweise dazu, zu versuchen, die Absicht einer bestimmten Implementierung zu erkennen.)
(Niedrigere Abstraktionssprachen bevorzugen aufgrund ihrer Betonung der Programmiererkontrolle die Verwendung der Kompilierung vor der Zeit. Die Kompilierung zur Installationszeit wird möglicherweise toleriert, obwohl die Auswahl der Implementierung zur Verbindungszeit eine bessere Kontrolle der Programmierer ermöglichen würde. Die JIT-Kompilierung opfert eine signifikante Kontrolle. )
Es gibt auch das Problem der Benchmarking-Methodik. Gleiche Anstrengungen / Fähigkeiten können effektiv nicht festgestellt werden, aber selbst wenn dies erreicht werden könnte, würden die Sprachziele die Ergebnisse beeinflussen. Wenn eine geringe maximale Programmierzeit erforderlich wäre, könnte ein Programm für eine weniger abstrakte Sprache im Vergleich zu einem einfachen idiomatischen Ausdruck in einer abstrakteren Sprache möglicherweise nicht vollständig geschrieben werden. Wenn eine hohe maximale Programmierzeit / -aufwand zulässig wäre, hätten Sprachen mit geringerer Abstraktion einen Vorteil. Benchmarks, die Best-Effort-Ergebnisse liefern, wären natürlich zugunsten weniger abstrakter Sprachen voreingenommen.
Es ist manchmal möglich, in einer Sprache weniger idiomatisch zu programmieren, um die Vorteile anderer Programmierparadigmen zu nutzen, aber selbst wenn die Ausdruckskraft verfügbar ist, sind die Kompromisse dafür möglicherweise nicht günstig.