¿Aceptable usar el acceso directo de IVAR desde fuera de la clase para obtener eficiencia?

Question

Puedo definir una clase con una propiedad para acceder a mis Ivars desde fuera de la clase.

También puedo usar la sintaxis de MyInst-> ivar para acceder a la moda C-Estruct.

En C ++, iría con accesorios, pero en Objetivo-C hay algunos casos en los que quiera acceso directo. El sistema de mensajería incurre en un gran éxito de rendimiento con el accesor que importa en algunos contextos, ya que el mensaje no se inserta como puede ser con los métodos C ++.

Por ejemplo, en una clase que tiene un Ivar llamado Scalar y una propiedad definida en ella. Scalar es un valor flotante simple:

-(void) doWorkWithMyClass:(MyClass*)myinst
{
   // array and other locals declaration omitted 
   for (int i = 0; i < reallyBigX; i++) {
      result += [myinst scalar] * array[i];
      [myinst computeNextScalar:i];
   }
}

Si cambio [MyInst Scalar] a MyInst-> Scalar, el método se ejecutará mucho más rápido, ya que usar llamadas con el accesor tomaría la mayor parte de la CPU en este bucle.

Al igual que con C ++, entiendo que el acceso directo a Ivar se desanimó en general, pero en este contexto, cuando la velocidad importa, ¿es aceptable? Si no, ¿hay un método más preferido que todavía use una clase Objective-C?

Answer 1

Muchas cosas se vuelven aceptables cuando tiene un impacto significativo en el rendimiento, pero en el ejemplo que está dando, parece haber soluciones mucho mejores.

Primero, ¿por qué no [myinst computeNextScalar:i] ¿Devolver el nuevo escalar? Si hicieras eso, no necesitarías buscarlo y todo sería mucho más rápido.

¿No se puede trasladar el trabajo myinst? Quiero decir, ¿no puedes crear algo como:

result = [myinst totalOverArray:array];

Si reallyBigX es realmente grande, entonces deberías considerar el acelerado. Puede mejorar significativamente el rendimiento en el tipo de operación que parece estar haciendo. (Debe realizar pruebas de rendimiento con el marco Acelerate. Puede ser sustancialmente más lento para algunas operaciones, pero esta podría ser más rápida).

Finalmente, considere el objetivo-C get... patrón. Se parece a esto:

int *scalars = calloc(reallyBigX, sizeof(int));
[myinst getScalars:scalars range:NSMakeRange(0, reallyBigX)];
for (int i = 0; i < reallyBigX; i++) {
   result += scalars[i] * array[i];
}
free(scalars);

Por cierto, lo anterior es definitivamente un candidato para vDSP_dotpr(), aunque debes probarlo. En muchos casos, el bucle simple es más rápido que un equivalente vDSP Llame cuando Stride = 1 (ya que puede usar un incremento simple en lugar de += stride).

Answer 2

Sí, es aceptable: el @public, @private, etc. Los modificadores de acceso se introdujeron en parte para admitir diseños donde se requiere acceder a IVAR desde fuera de la clase. Sin embargo, debe evitar escribir directamente a Ivars.