Discussion :

[camboui]

Voici l'esprit de l'ancien code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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

Ça tourne comme une horloge depuis 15 ans

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

[Matt_Houston]

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.

[Luc Hermitte]

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.

[Oscar.STEFANINI]

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

[Bousk]

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.