Apprendre � programmer avec C++14 et C++17 pour des codes plus rapides et performants

Voici l'esprit de l'ancien code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

struct Personne { unsigned id; const char *nom; const char *prenom; unsigned datenaissance; };   // StringInterning allocates a string only once and keeps it in memory "forever" class StringInterning { MemoryLeaker f_memLeak; HashTpl<char,char> f_strMap; unsigned f_stat_inserts,f_stat_empties,f_stat_strings; public: StringInterning(unsigned reserve=511*1024u,unsigned primenumber=786433u,unsigned memoryLeakerBlockSize=8*1023*1024); ~StringInterning(); static const char *GetEmptyStr(); const char *Insert(const char *s,unsigned slen); const char *Insert(const string & s) {return Insert(s,s.length());} string Stats(); };   void main() { StringInterning si; ... Personne p; p.prenom = si.Insert(newvalue); ... }

---

Et voici l'esprit du nouveau et "moderne" C++ ;):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

struct personne { unsigned id; string nom; string prenom; unsigned datenaissance; };     void main() { ... Personne p; p.prenom = newvalue; ... }

---

Dans le code il y a une 20aine de structures du genre Personne avec en moyenne une 10aine de membres. Pour info, le dernier traitemant (ce matin) g�rait 40.901.836 pointeurs const char * pour 3.225.807 chaines distinctes r�parties dans ces structures (la DB charg�e enti�rement en m�moire).
Une fois le traitement effectu�, la m�moire du "string interning" est lib�r�e en une fois (j'aurais d� dire "fuite de m�moire control�e").

Je pense qu'il est facile de comprendre que l'usage d'un "string interning" est bien plus performant que de laisser 40.901.836 std::string g�rer chacun son petit buffer de m�moire tout seul.

Citation:

---

Envoy� par koala01

Ceci dit, s'il y avait effectivement des fuites m�moires volontaires, ca laisse entrevoir des probl�mes sans nom dus � la perte de ressources sur les syst�mes anciens :P

---

�a tourne comme une horloge depuis 15 ans :zen:

Citation:

---

Envoy� par koala01

Par contre, pour ce qui est de la lenteur et de l'occupation de la m�moire, peut-�tre y a-t-il encore "quelque chose" � faire ;)

---

Je suis tout ou�e ;)

C'est une � arena �, une allocation en masse sur le tas en pr�vision d'un usage intensif. C'est courant en embarqu�, dans le jeu vid�o ou pour des applications critiques.

Pour des string on doit pouvoir impl�menter �a en surchargeant l'allocateur.

Plut�t que �a, je pr�f�rerai employer des string_view dans le buffer pr�allou�.
Mais, on peut aussi se tourner vers des allocateurs d�di�s aux petits objets (cf Modern C++ Design de A.Alexandrescu). Et voir aussi que les chaines de VC++/dinkumware (et possiblement celles conformes au standard de 2011 chez libstdc++ -- pas celles par d�faut jusqu'� g++5 compris) utilisent l'optimisation appel�e Small String Optimisation, ce qui peut d�gager les allocations pour les chaines de moins de 20 ou 30 bytes, je ne sais plus.

Apr�s, il ne faut pas n�gliger l'�limination des copies inutiles en for�ant au maximum l'utilisation de constructeurs au lieu de "Personne p; p.nom = toto". Et voir aussi ce que le d�placement peut apporter dans le cas de chaines stock�es dans des conteneurs.

�a fais beaucoup de chose pour un d�butant comme moi ^^

En gros tu as une pool de strings, un super-cache, je ne vois pas o� se situerait un probl�me ?
Comme le dit Matt c'est assez courant. Et �a permet des optimisations sympas, comme la comparaison de strings qui se r�soudrait � comparer un simple pointeur. :P