OMI sí, pero para una el diseño fundamental es mucho más sutil y complejo que el despacho virtual o las consultas de interfaz tipo COM o los metadatos de objeto necesarios para la información del tipo de tiempo de ejecución o algo así. Hay una sobrecarga asociada con todo eso, pero depende en gran medida del lenguaje y compilador (s) utilizado, y también depende de si el optimizador puede eliminar dicha sobrecarga en tiempo de compilación o tiempo de enlace.Sin embargo, en mi opinión hay una razón más amplia conceptual razón por la codificación de una interfaz implica (no garantías) un impacto en el rendimiento:
Codificación a una interfaz implica que hay una barrera entre usted y los datos concreto/memoria que desea para acceder y transformar
Esta es la razón principal por la que veo. Como ejemplo muy simple, digamos que tiene una interfaz de imagen abstracta. Se abstrae completamente sus detalles concretos, como su formato de píxeles. El problema aquí es que a menudo las operaciones de imagen más eficientes necesitan esos detalles concretos. No podemos implementar nuestro filtro de imagen personalizado con instrucciones SIMD eficientes, por ejemplo, si tuviéramos que llamar a getPixel de a uno por vez y setPixel uno a la vez y sin tener en cuenta el formato de píxel subyacente.
Por supuesto, la imagen abstracta podría tratar de proporcionar todas estas operaciones, y esas operaciones podrían implementarse muy eficientemente ya que tienen acceso a los detalles internos privados de la imagen concreta que implementa esa interfaz, pero eso solo se sostiene como siempre que la interfaz de la imagen proporcione todo lo que el cliente alguna vez quiera hacer con una imagen.
A menudo, en algún punto una interfaz no puede proporcionar todas las funciones imaginables al mundo entero, por lo que tales interfaces, cuando se enfrentan a preocupaciones de rendimiento crítico y al mismo tiempo necesitan satisfacer una amplia gama de necesidades, a menudo detalles. La imagen abstracta aún puede proporcionar, por ejemplo, un puntero a sus píxeles subyacentes a través de un método pixels() que en gran medida frustra mucho del propósito de la codificación en una interfaz, pero a menudo se convierte en una necesidad en las áreas más críticas para el rendimiento.
En general, muchos de los códigos más eficientes a menudo tienen que escribirse con detalles muy concretos en algún nivel, como el código escrito específicamente para coma flotante de precisión simple, código escrito específicamente para imágenes RGBA de 32 bits, código escrito específicamente para GPU, específicamente para AVX-512, específicamente para hardware móvil, etc. Así que hay una barrera fundamental, al menos con las herramientas que tenemos hasta ahora, donde no podemos abstraer todo eso y simplemente codificar una interfaz sin una implícita pena.
Por supuesto, nuestras vidas serían mucho más sencillas si pudiéramos simplemente escribir código, ajenos a todos los detalles concretos, como si estamos trabajando con SPFP de 32 bits o DPFP de 64 bits, si estamos escribiendo sombreadores en un dispositivo móvil limitado o una computadora de escritorio de alta gama, y todo es el código más competitivo y competitivo que existe. Pero estamos lejos de esa etapa. Nuestras herramientas actuales a menudo requieren que escribamos nuestro código de rendimiento crítico contra detalles concretos.
Y, por último, este es un problema de granularidad. Naturalmente, si tenemos que trabajar con cosas píxel por píxel, cualquier intento de abstraer detalles concretos de un píxel podría ocasionar una importante penalización del rendimiento. Pero si estamos expresando cosas en el nivel de la imagen como "mezclar alfa estas dos imágenes juntas", podría ser un costo muy despreciable, incluso si hay una sobrecarga de despacho virtual y demás. Entonces, a medida que trabajamos hacia un código de nivel superior, a menudo cualquier penalización implícita en el rendimiento de la codificación a una interfaz disminuye hasta el punto de volverse completamente trivial. Pero siempre existe la necesidad del código de bajo nivel, que sí hace cosas como procesar cosas píxel por píxel, recorriendo millones de ellas muchas veces por fotograma, y allí el costo de codificación en una interfaz puede llevar una bonita penalidad sustancial, aunque solo sea porque está ocultando los detalles concretos necesarios para escribir la implementación más eficiente.
Su pregunta todavía es válida pero está diciendo mal el nombre del hombre. Él está diciendo que proporcionar las interfaces * simplemente para proporcionar simulaciones para las pruebas unitarias * no valía la pena el rendimiento alcanzado. Lo cual puedo ver su punto. –
No lo sé. ¿Cuánto de un golpe de perforación serviría?¿Cuánto vale para ti poder probar algo? –