Discussion :

[Klaim]

Bonjour!

J'ai une question qui concerne plus ou moins de l'optimization, mais aussi la façon dont un compilo gère les namespaces et plus précisément les variables globales "enfermées" dans des namespaces.

Dans le document suivant consacré à l'optimization en C++, on peut lire à la page 24 :

The advantage of static data is that they can be initialized to desired values before the
program starts. The disadvantage is that the memory space is occupied throughout the
whole program execution, even if the variable is only used in a small part of the program.
This makes data caching less efficient.
Do not make variables global if you can avoid it. Global variables may be needed for
communication between different threads, but that’s about the only situation where they are
unavoidable. It may be useful to make a variable global if it is accessed by several different
functions and you want to avoid the overhead of transferring the variable as function
parameter. But it may be a better solution to make the functions that access the saved
variable members of the same class and store the shared variable inside the class. Which
solution you prefer is a matter of programming style.

Source : http://www.agner.org/optimize/ le premier PDF.

Vu le conseil donné ici de complètement éviter les variables globales (non constantes), je me demandais si le fait de les encapsuler dans des espaces de nom n'aidait pas à indiquer au compilo de ne pas charger en permanence les dites variables (a ce que j'ai compris). Ou bien les espaces de noms sont-ils uniquement gérés comme des extension des noms des variables?

Je me demandais ça parceque la configuration (provenant d'un .ini) de mon application est actuellement reflétée par des variables globales (les seules de l'application si on omet les membres statiques de classes) qui peuvent potentiellement être modifées par pas mal de code différent, donc ça me semblait plus naturel de simplement les encapsuler dans un namespace plutot que de faire une classe avec uniquement des membres statiques (vu que je ne veux pas d'instanciation). (note : ce ne sont que des types de bases ou des std::string)

Je me demande aussi si ça vaut vraiment le coup de se poser la question : est-ce que ça peut vraiment plomber des perfs globales a cause de l'impact sur la stack ou est-ce que c'est tellement mineur que je peux oublier jusqu'à ce que ça pose de manière évidente un problème de perf?

[JolyLoic]

Qu'elles soient globales dans ::, globales dans un namespace, ou variables statiques de classe n'a à mon avis absolument aucun impact en terme de perfs. Et en terme de qualité de design du code non plus : C'est aussi problématique dans un cas que dans l'autre.

[zais_ethael]

Je ne sais pas d'où tu tires ce petit speech, mais il n'est pas génial.
Pour ce qui est de l'utilisation mémoire, ça revient bien entendu au même d'initialiser une donnée au début du main -> si c'est utilisé dans tout le programme ça occupe inévitablement de la mémoire pendant toute l'exécution du programme.
Et pour ce qui est de l'aspect multithread, et bien il se trouve justement qu'elles sont bien souvent la cause de problème dans ces programmes (haaa, les fonctions de manipulation de date en C).
Pour résumer grossièrement, le seul cas qui nécessite réellement une variable globale ou statique (statique, en C++, c'est mieux) c'est lors de l'utilisation d'un pattern singleton (et encore, faut protéger ça à coup de mutex quand on est un programmeur consciencieux, et ça ça a un impact sur les perfs).

[Alp]

Pour résumer grossièrement, le seul cas qui nécessite réellement une variable globale ou statique (statique, en C++, c'est mieux) c'est lors de l'utilisation d'un pattern singleton (et encore, faut protéger ça à coup de mutex quand on est un programmeur consciencieux, et ça ça a un impact sur les perfs).

Je suis malheureusement tout à fait d'accord

[Klaim]

Ok donc j'ai pas trop a m'en soucier finalement...

Au passage l'auteur du document dit aussi que les appels fonction de DLL sont plus lent que les appels aux fonctions en statique. On m'avait dit le contraire (comme quoi une fois les dll chargé en mémoire ça revenais au même).
En lisant ça du coup je commence a douter. Est-ce que quelqu'un peut me copnfirmer dans un sens ou un autre?

Ya des infos d'optimization interessantes dans ce doc mais ya des parties sur lesquelles j'ai de sérieux doute par rapport a ce que j'ai lu autre part....

[ram-0000]

Je ne voie pas en quoi appeller un fonction dans une DLL serait plus long que d'appeler cette meme fonction dans le programme (je ne suis même pas sûr que ce que je viens de dire aie un sens ).

Attention, je dit bien "APPELER", pas "CHARGER" la DLL car le temps de chargement d'une DLL et le process de relocation des appels n'est pas nul.

[Emmanuel Deloget]

Pour résumer grossièrement, le seul cas qui nécessite réellement une variable globale ou statique (statique, en C++, c'est mieux) c'est lors de l'utilisation d'un pattern singleton (et encore, faut protéger ça à coup de mutex quand on est un programmeur consciencieux, et ça ça a un impact sur les perfs).

std::cout ? (+ version wchar_t)
std::cin ? (+ version wchar_t)
std::cerr ? (+ version wchar_t)
std::clog ? (+ version wchar_t)

Pour ma part, je ne pense pas que le pattern singleton ajoute quoi que ce soit à une instance globale (et il n'y a pas de réelle différence entre une statique de classe et une instance globale).

[JolyLoic]

Pour ma part, je ne pense pas que le pattern singleton ajoute quoi que ce soit à une instance globale.

Plus de possibilité sur l'ordre d'initialisation des données.

[philmor34]

faut relativiser pour les appels dll qui sont plus lents.

générallement, tu utilise que quelques fonctions de la DLL dans ton code, et les fonctions de la DLL appelle les fonctions dans la DLL, qui celles-là, n'ont pas besoin de passer par la table d'indirection

et j'ai comparé il y a quelques semaines la différence sur plusieurs appels de fonctions dans une DLL contre une dans une statique, la différence était minime.

quand tu développe, tu dois pas te préoccuper de l'optimisation de ton code, mais seulement arriver a quelque chose qui fonctionne. Ensuite, tu utilise un programme pour voir ou tu peut optimiser ton code

parce qu'en général, les ralentissements ne sont pas là ou tu pense