¿Cuándo usar la función en línea y cuándo no usarla?

Sé que en línea es una sugerencia o solicitud para el compilador y se usa para evitar gastos generales de llamadas a funciones.

Entonces, ¿sobre qué base se puede determinar si una función es candidata para alinearse o no? ¿En qué caso se debe evitar la inserción?

Evitar el costo de una llamada a funciones es solo la mitad de la historia.

hacer:

• usar en inlinelugar de#define
• las funciones muy pequeñas son buenas candidatas para inline: código más rápido y ejecutables más pequeños (más posibilidades de permanecer en el caché de código)
• la función es pequeña y se llama con mucha frecuencia

no:

• funciones grandes: conduce a ejecutables más grandes, lo que perjudica significativamente el rendimiento independientemente de la ejecución más rápida que resulta de la sobrecarga de llamadas
• funciones en línea que están vinculadas a E / S
• la función rara vez se usa
• constructores y destructores: incluso cuando está vacío, el compilador genera código para ellos
• romper la compatibilidad binaria al desarrollar bibliotecas:
  • en línea una función existente
  • cambiar una función en línea o hacer que una función en línea no esté en línea: la versión anterior de la biblioteca llama a la implementación anterior

al desarrollar una biblioteca, para que una clase sea extensible en el futuro, debe:

• agregar destructor virtual no en línea incluso si el cuerpo está vacío
• hacer que todos los constructores no estén en línea
• escribir implementaciones no en línea del constructor de copia y el operador de asignación a menos que la clase no se pueda copiar por valor

Recuerde que la inlinepalabra clave es una pista para el compilador: el compilador puede decidir no incluir una función en línea y puede decidir incluir funciones que no se marcaron inlineen primer lugar. En general, evito marcar la función inline(aparte, tal vez cuando escribo funciones muy muy pequeñas).

En cuanto al rendimiento, el enfoque inteligente es (como siempre) perfilar la aplicación, y finalmente inlineun conjunto de funciones que representan un cuello de botella.

Referencias

• En línea o no en línea
• [9] Funciones en línea
• Políticas / Problemas de compatibilidad binaria con C ++
• GotW # 33: en línea
• Redux en línea
• C ++ efectivo - Elemento 33: Use juiciosamente en línea

EDITAR: Bjarne Stroustrup, El lenguaje de programación C ++:

Una función se puede definir para ser inline. Por ejemplo:

inline int fac(int n)
{
  return (n < 2) ? 1 : n * fac(n-1);
}

El inlineespecificador es una pista para el compilador de que debería intentar generar código para una llamada en fac()línea en lugar de establecer el código para la función una vez y luego llamar a través del mecanismo habitual de llamada de función. Un compilador inteligente puede generar la constante 720para una llamada fac(6). La posibilidad de funciones en línea recursivas mutuamente, funciones en línea que se repiten o no dependen de la entrada, etc., hace que sea imposible garantizar que cada llamada de una inlinefunción esté realmente en línea. El grado de inteligencia de un compilador no se puede legislar, por lo que un compilador puede generar 720, otro 6 * fac(5), y otro más una llamada no en línea fac(6).

Para hacer posible la alineación en ausencia de facilidades de compilación y enlace inusualmente inteligentes, la definición, y no solo la declaración, de una función en línea debe estar dentro del alcance (§9.2). Un inlineespecificador no afecta la semántica de una función. En particular, una función en línea todavía tiene una dirección única y también tiene staticvariables (§7.1.2) de una función en línea.

EDIT2: ISO-IEC 14882-1998, 7.1.2 Especificadores de funciones

Una declaración de función (8.3.5, 9.3, 11.4) con un inlineespecificador declara una función en línea. El especificador en línea indica a la implementación que la sustitución en línea del cuerpo de la función en el punto de llamada debe preferirse al mecanismo habitual de llamada a la función. No se requiere una implementación para realizar esta sustitución en línea en el punto de llamada; sin embargo, incluso si se omite esta sustitución en línea, se seguirán respetando las otras reglas para las funciones en línea definidas en 7.1.2.

inlinetiene muy poco que ver con la optimización. inlinees una instrucción para el compilador de no producir un error si la definición de la función dada ocurre varias veces en el programa y una promesa de que la definición se producirá en cada traducción que se use y en todas partes que aparezca tendrá exactamente la misma definición.

Dadas las reglas anteriores, inlinees adecuado para funciones cortas cuyo cuerpo no necesita incluir dependencias adicionales sobre lo que necesitaría una declaración. Cada vez que se encuentra la definición, se debe analizar y se puede generar código para su cuerpo, por lo que implica una sobrecarga del compilador sobre una función definida solo una vez en un solo archivo fuente.

Un compilador puede en línea (es decir, reemplazar una llamada a la función con código que realiza esa acción de esa función) cualquier llamada de función que elija. Solía ​​ser el caso de que "obviamente" no podía alinear una función que no se declaró en la misma unidad de traducción que la llamada, pero con el uso creciente de la optimización del tiempo de enlace, incluso esto no es cierto ahora. Igualmente cierto es el hecho de que las funciones marcadas inlinepueden no estar en línea.

Decirle al compilador que alinee una función es una optimización, y la regla más importante de la optimización es que la optimización prematura es la raíz de todo mal. Siempre escriba código claro (usando algoritmos eficientes), luego perfile su programa y solo optimice las funciones que están tardando demasiado.

Si encuentra que una función en particular es muy corta y simple, y se llama decenas de miles de veces en un circuito interno cerrado, podría ser un buen candidato.

Sin embargo, es posible que se sorprenda: muchos compiladores de C ++ incorporarán automáticamente pequeñas funciones para usted, e incluso podrían ignorar su solicitud.

La mejor manera de averiguarlo es crear un perfil de su programa y marcar pequeñas funciones que se llaman muchas veces y grabar ciclos de CPU de esa manera inline. La palabra clave aquí es "pequeña": una vez que la sobrecarga de la llamada de función es insignificante en comparación con el tiempo dedicado a la función, no tiene sentido alinearlos.

El otro uso que sugeriría es que si tiene funciones pequeñas que se llaman en el código crítico de rendimiento con la frecuencia suficiente para hacer que una memoria caché pierda relevancia, probablemente también debería incluirlas. De nuevo, es algo que el perfilador debería poder decirte.

¡La optimización temprana es la raíz de todo mal!

Como regla general, generalmente solo incluyo "getters" y "setters". Una vez que el código funciona y es estable, la creación de perfiles puede mostrar qué funciones podrían beneficiarse de la incorporación.

Por otro lado, la mayoría de los compiladores modernos tienen algoritmos de optimización bastante buenos, y alinearán lo que debería haber alineado para usted.

Reasumir: escriba funciones de línea única y se preocupe por las demás más adelante.

Las funciones en línea pueden mejorar el rendimiento de su código al eliminar la necesidad de insertar argumentos en la pila. si la función en cuestión está en una parte crítica de su código, debe tomar la decisión en línea, no en línea, en la parte de optimización de su proyecto,

puedes leer más sobre las líneas en las preguntas frecuentes de c ++

A menudo uso las funciones en línea no como una optimización, sino para hacer que el código sea más legible. A veces, el código en sí es más corto y más fácil de entender que los comentarios, los nombres descriptivos, etc. Por ejemplo:

void IncreaseCount() { freeInstancesCnt++; }

El lector conoce de inmediato la semántica completa del código.

Generalmente sigo una regla de pulgar donde hago una función con 3-4 declaraciones simples como en línea. Pero es bueno recordar que es solo una pista para el compilador. La última llamada para que esté en línea o no la toma el compilador únicamente. Si hay más de estas muchas declaraciones, no declararé en línea, ya que con un compilador estúpido, puede provocar una acumulación de código.

La mejor manera sería examinar y comparar las instrucciones generadas para en línea y no en línea. Sin embargo, siempre es seguro omitirlo inline. Usar inlinepodría generar problemas que no quieres.

Cuando decido si usar en línea, generalmente tengo en cuenta la siguiente idea: en las máquinas modernas, la latencia de memoria puede ser un cuello de botella más grande que los cálculos en bruto. Se sabe que las funciones de línea que se llaman a menudo aumentan el tamaño del ejecutable. Además, dicha función podría almacenarse en el caché de código de la CPU, lo que disminuirá el número de errores de caché cuando se necesite acceder a ese código.

Por lo tanto, tiene que decidir por usted mismo: ¿la alineación aumenta o disminuye el tamaño del código máquina generado? ¿Qué tan probable es que llamar a la función cause una pérdida de caché? Si está salpicado en todo el código, entonces diría que la probabilidad es alta. Si está restringido a un solo ciclo cerrado, entonces la probabilidad es baja.

Normalmente uso inlining en los casos que enumero a continuación. Sin embargo, cuando está realmente preocupado por el rendimiento, la creación de perfiles es esencial. Además, es posible que desee comprobar si el compilador realmente toma la pista.

• Rutinas cortas que se llaman en un ciclo cerrado.
• Accesores muy básicos (get / set) y funciones de envoltura.
• El código de plantilla en los archivos de encabezado desafortunadamente obtiene automáticamente la pista en línea.
• Código corto que se usa como una macro. (Por ejemplo, min () / max ())
• Cortas rutinas de matemáticas.

Además, un método en línea tiene graves efectos secundarios al mantener proyectos grandes. Cuando se cambia el código en línea, el compilador reconstruirá automáticamente todos los archivos que lo utilizan (es un buen compilador). Esto podría desperdiciar mucho tiempo de desarrollo.

Cuando un inlinemétodo se transfiere a un archivo fuente y ya no está en línea, se debe reconstruir todo el proyecto (al menos esta ha sido mi experiencia). Y también cuando los métodos se convierten en línea.

Uno debería usar el calificador de función en línea solo cuando el código de la función es pequeño. Si las funciones son más grandes, debería preferir las funciones normales ya que el ahorro en espacio de memoria vale el sacrificio comparativamente pequeño en la velocidad de ejecución.

Cuando piense que su código es lo suficientemente pequeño como para usarlo en línea y recuerde que la función en línea duplica su código y péguelo donde se llama la función, por lo que puede ser lo suficientemente bueno como para aumentar su tiempo de ejecución pero también un mayor consumo de memoria. No puede usar la función en línea cuando está usando un bucle / variable estática / recursiva / switch / goto / función virtual. Virtual significa esperar hasta el tiempo de ejecución e inline significa durante la compilación para que no puedan usarse simultáneamente.

He leído algunas respuestas y veo que faltan algunas cosas.

La regla que uso es no usar en línea, a menos que quiera que esté en línea. Parece tonto, ahora explicación.

Los compiladores son lo suficientemente inteligentes y las funciones cortas siempre están en línea. Y nunca hace una función larga como en línea, a menos que el programador diga que lo haga.

Sé que en línea es una pista o solicitud para compilar

En realidad inlinees un pedido para el compilador, no tiene opciones y después de que la inlinepalabra clave hace que todo el código esté en línea. Por lo tanto, nunca puede usar inlinepalabras clave y el compilador diseñará el código más corto.

Entonces, ¿cuándo usarlo inline?

Para usar si quieres tener algún código en línea. Solo conozco un ejemplo, porque lo uso en una sola situación. Es autenticación de usuario.

Por ejemplo tengo esta función:

inline bool ValidUser(const std::string& username, const std::string& password)
{
    //here it is quite long function
}

No importa cuán grande sea esta función, quiero tenerla en línea porque hace que mi software sea más difícil de descifrar.