Por su naturaleza, la abstracción reduce la comunicación de información, tanto para el programador como para las capas inferiores del sistema (el compilador, las bibliotecas y el sistema de tiempo de ejecución). A favor de la abstracción, esto generalmente permite que las capas inferiores asuman que el programador no está preocupado por ningún comportamiento no especificado, proporcionando una mayor flexibilidad para suministrar el comportamiento que se especifica.
Un ejemplo de un beneficio potencial de este aspecto de "no me importa" es el diseño de datos. En C (baja abstracción), el compilador está más limitado en las optimizaciones de diseño de datos. Incluso si el compilador pudiera discernir (p. Ej., A través de la información del perfil) que las optimizaciones para evitar el intercambio de calor / frío o falsas acciones serían beneficiosas, generalmente se impide su aplicación. (Existe cierta libertad para especificar "como si", es decir, tratar la especificación de manera más abstracta, pero derivar todos los efectos secundarios potenciales agrega una carga al compilador).
Una especificación más abstracta también es más robusta frente a los cambios en las compensaciones y usos. Las capas inferiores están menos restringidas para reoptimizar el programa para nuevas características del sistema o nuevos usos. Un programador debe reescribir una especificación más concreta o las capas inferiores deben hacer un esfuerzo adicional para garantizar un comportamiento "como si".
El aspecto que obstaculiza el rendimiento de la abstracción de ocultación de información es "no se puede expresar", que las capas inferiores generalmente manejarán como "no sé". Esto significa que las capas inferiores deben discernir la información útil para la optimización de otros medios, como el uso general típico, el uso específico o la información específica del perfil.
El impacto del ocultamiento de información también funciona en la otra dirección. El programador puede ser más productivo al no tener que considerar y especificar cada detalle, pero el programador puede tener menos información sobre el impacto de las elecciones de diseño de nivel superior.
Por otro lado, cuando el código es más específico (menos abstracto), las capas más bajas del sistema pueden hacer más simplemente lo que se les pide que hagan. Si el código está bien escrito para su uso específico, se ajustará bien a su uso específico. Un lenguaje menos abstracto (o paradigma de programación) permite al programador optimizar la implementación mediante un diseño detallado y mediante el uso de información que no se comunica fácilmente en un lenguaje determinado a las capas inferiores.
Como se ha señalado, los lenguajes menos abstractos (o técnicas de programación) son atractivos cuando la habilidad y el esfuerzo adicionales del programador pueden producir resultados valiosos. Cuando se aplica más esfuerzo y habilidad del programador, los resultados generalmente serán mejores. Además, un sistema de lenguaje que se usa menos para aplicaciones críticas para el rendimiento (en lugar de enfatizar el esfuerzo de desarrollo o la confiabilidad, las verificaciones de límites y la recolección de basura no se trata solo de la productividad del programador, sino de la corrección, la abstracción que reduce la carga mental en el programador puede mejorar la confiabilidad) tendrá menos presión para mejorar el rendimiento.
La especificidad también funciona en contra del principio de no repetirse porque la optimización generalmente es posible al adaptar el código a un uso específico. Esto tiene implicaciones obvias de confiabilidad y esfuerzo de programación.
Las abstracciones proporcionadas por un lenguaje también pueden incluir trabajo no deseado o innecesario sin medios para elegir una abstracción menos pesada. Si bien a veces las capas inferiores pueden descubrir y eliminar el trabajo innecesario (por ejemplo, las comprobaciones de límites pueden extraerse del cuerpo de un bucle y eliminarse por completo en algunos casos), determinar que se trata de una optimización válida requiere más "habilidad y esfuerzo" El compilador.
La edad y la popularidad del idioma también son factores notables tanto en la disponibilidad de programadores calificados como en la calidad de las capas inferiores del sistema (incluidas bibliotecas maduras y ejemplos de código).
Otro factor de confusión en tales comparaciones es la diferencia algo ortogonal entre la compilación anticipada y la compilación justo a tiempo. Si bien la compilación justo a tiempo puede explotar más fácilmente la información de perfil (no depender del programador para proporcionar ejecuciones de perfil) y la optimización específica del sistema (la compilación anticipada puede apuntar a una compatibilidad más amplia), la sobrecarga de la optimización agresiva se contabiliza como parte del rendimiento del tiempo de ejecución. Los resultados JIT se pueden almacenar en caché, lo que reduce la sobrecarga para el código de uso común. (La alternativa de la reoptimización binaria puede proporcionar algunas ventajas de la compilación JIT, pero los formatos de distribución binarios tradicionales eliminan la mayoría de la información del código fuente, lo que puede forzar al sistema a intentar discernir la intención de una implementación específica).
(Los lenguajes de abstracción más bajos, debido a su énfasis en el control del programador, favorecen el uso de la compilación anticipada. La compilación de tiempo de instalación podría ser tolerada, aunque la selección de implementación de tiempo de enlace proporcionaría un mayor control del programador. La compilación JIT sacrifica el control significativo. )
También está la cuestión de la metodología de evaluación comparativa. Igual esfuerzo / habilidad es efectivamente imposible de establecer, pero aun así se podría lograr que los objetivos del lenguaje sesgarían los resultados. Si se requiere un tiempo de programación máximo bajo, un programa para un lenguaje menos abstracto podría fallar incluso si se escribe por completo en comparación con una expresión idiomática simple en un lenguaje más abstracto. Si se permitiera un tiempo / esfuerzo de programación máximo alto, los lenguajes de abstracción más baja tendrían una ventaja. Los puntos de referencia que presentan los mejores resultados de esfuerzo naturalmente estarían sesgados a favor de lenguajes menos abstractos.
A veces es posible programar de una manera menos idiomática en un lenguaje para obtener las ventajas de otros paradigmas de programación, pero incluso cuando el poder expresivo está disponible, las compensaciones por hacerlo pueden no ser favorables.