Non, tu te trompes lourdement. Il y a plein de cas ou l'inlining est plus petit. Un getter/setter inliné peut réduire le code de la fonction appelante, alors qu'un call prend 2 instructions. C'est vrai pour chaque fonction appelante.
Tu as aussi les cas à plusieurs branches, où la simplification s’arrête faute d'information, si la propagation de constante continue, une partie entière de code disparait.
J'ai aussi le cas de constante composé à coup de "PLOP | PLIP" qui ne font que changer une constante de code, au lieu d'un appel de fonction, avec sauvegarde des registres.
Ton postulat faux de base est que l'inline ajoute toujours du code, et que dans le bilan il faut retirer le code d'appel et tenir compte du code de la fonction elle-même. Mais dans les faits, pour certaine fonctions, cela simplifie tellement le code appelant, que pour chaque inline, la fonction appelante est réduite.
[^] # Re: la performance par l'inlining
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Si si, le C++ peut parfois être plus rapide que le C. Évalué à 2.
Non, tu te trompes lourdement. Il y a plein de cas ou l'inlining est plus petit. Un getter/setter inliné peut réduire le code de la fonction appelante, alors qu'un call prend 2 instructions. C'est vrai pour chaque fonction appelante.
Tu as aussi les cas à plusieurs branches, où la simplification s’arrête faute d'information, si la propagation de constante continue, une partie entière de code disparait.
J'ai aussi le cas de constante composé à coup de "PLOP | PLIP" qui ne font que changer une constante de code, au lieu d'un appel de fonction, avec sauvegarde des registres.
Ton postulat faux de base est que l'inline ajoute toujours du code, et que dans le bilan il faut retirer le code d'appel et tenir compte du code de la fonction elle-même. Mais dans les faits, pour certaine fonctions, cela simplifie tellement le code appelant, que pour chaque inline, la fonction appelante est réduite.
"La première sécurité est la liberté"