Discussion :

[Feriaman]

Bonjour,

J'aimerais vous soumettre le probl�me suivant :

L'un des programmes que j'utilise lit des fichiers dans divers formats.

Une premi�re couche g�n�re � partir de ces fichiers, des objets temporaires qu'il passe ensuite � une seconde couche qui les v�rifie et instancie mon mod�le de donn�e.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
fichier format A --> [Brique A] -\
fichier format B --> [Brique B] ----> Objet intermédiaire ---> [traducteur] ---> Mon Modèle
fichier format C --> [Brique C] -/

L'int�r�t de passer par cette couche interm�diaire r�side dans le fait que les diff�rents formats lus sont stables, alors que mon mod�le est sujet � variations, je n'ai donc qu'une unique brique � modifier lorsque je change mon mod�le.
Les inconv�nients sont nombreux, mais il n'en est pas question ici.

Mon probl�me est d'optimiser l'une des briques qui lit les objets temporaire.
Cette brique utilise un unique objet de chaque type, le remplit au fur et � mesure, avant de la passer � ma seconde couche.
Elle le r�initialise ensuite, puis recommen�e sa lecture.

Pour le moment, la r�initialisation est faite atomiquement, c'est � dire qu'elle ressemble � �a :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
MonObjetTemporaireDeTypeCapitaine::Reinit()
{
	m_iAgeDuCapitaine = -1;
	m_fTailleDuCapitaine = -1.0F;
	m_pFemmeDuCapitaine = NULL;
	m_sNomDuCapitaine = "unamed";
	...
}

Mais je me disais que je pourrais gagner du temps en cr�ant un second objet temporaire avec mes valeurs par d�faut avec ces valeurs et le copier � chaque fois pour r�initialiser l'autre (Je pense m�me qu'il s'agit d'un DP de cr�ation).

L'id�e �tant que la copie d'un bloc de m�moire de n octets est plus rapide que la copie de n blocks de m�moire de 1 octet. Il faut donc que je veille � ce que mon constructeur par recopie utilise bien une copie d'un block.

Je peux m'en sortir en faisant quelque chose comme �a :

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
 
struct SDonneeCopiablesDuCapitaine
{
	int m_iAgeDuCapitaine;
	float m_fTailleDuCapitaine;
	Individu* m_pFemmeDuCapitaine;
};
struct SDonneeNonCopiablesDuCapitaine
{
	std::string m_sNomDuCapitaine;
};
struct SDonneesDuCapitaine
{
	SDonneeCopiablesDuCapitaine dc;
	SDonneeNonCopiablesDuCapitaine dnc;
};
struct SDonneesAlternativesDuCapitaine
{
	char dc[sizeof(SDonneeCopiablesDuCapitaine )];
	SDonneeNonCopiablesDuCapitaine dnc;
};
class MonObjetTemporaireDeTypeCapitaine
{
	union
	{
		SDonneesDuCapitaine dc;
		SDonneesAlternativesDuCapitaine dac;
	}
};

ce qui me permettrait de construire mon constructeur par recopie comme �a :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
MonObjetTemporaireDeTypeCapitaine::MonObjetTemporaireDeTypeCapitaine(MonObjetTemporaireDeTypeCapitaine& toCopy)
{
	dac.dc = tocopy.dac.dc;		// ceci est une copie de tableau plus rapide qu'une somme de copies atomiques.
	dac.dnc = tocopy.dac.dnc ;	// ceci est une suite de copies atomiques.
}

Cette fa�on de faire est un peu p�nible car elle rend assez difficilement accessible mes donn�es, et elle semble assez peu �volutive.

Les questions que je me pose avant de commen�er � r�aliser cette optimisation sont :
- Existe-t-il une fa�on plus �l�gante de g�rer ce probl�me ?
- Est-ce seulement intelligent de le faire (peut-�tre le compilateur le fait-il pour moi sans que je le sache) ?
- Y a-t-il moyen d'automatiser la cr�ation des structures et des accesseurs en utilisant des template et des typelist. Le principal obstacle que je discerne �tant, dans un typelist : comment reconnaitre un type copiable d'un type non-copiable ?

Merci d'avoir lu.
Merci � ceux qui r�pondront.

[Jan Rendek]

Est-ce un cas d'�tude, ou as-tu un r��l probl�me de performance ?
Le DP auquel tu fais r�f�rence pourrait-�tre 'Prototype'.

La plupart des compilateurs optimisent correctement la copy des PODs.
Regrouper tes variables membres de type simple dans une structure permettra s�rement de les copier bit � bit. Il faudrait test� n�anmoins, le gain de rapidit� entre la copie successibe de chaque membre de type simple et celle d'une structure englobante.
Ce que je ne comprends pas en revanche c'est l'inter�t de regrouper les types 'complexes' dans une seconde structure.
Attention n�anmoins en subsituant l'appel d'une fonction de r�initialisation par celui d'un constructeur de copie. S'il y a allocation m�moire, il y aura n�cessairement un surco�t � moins de passer par un 'placement new'.

[loufoque]

Normalement la r�initialisation �a se fait en cr�ant un nouvel objet non ? Avec un swap �ventuel.

[Patriarch24]

Mon probl�me est d'optimiser l'une des briques qui lit les objets temporaire.

As-tu un r�el probl�me de performances ? Plut�t que de r�utiliser toujours le m�me objet pour la lecture, construits-en un nouveau. L'utilisation d'un prototype peut aussi �tre une bonne id�e, mais cela suppose une construction par copie d'un objet.

A l'arriv�e, et � moins que tu ne sois � une instruction machine pr�s, je te conseille de cr�er un objet � chaque fois.
Ou alors, si tu tiens vraiment � r�utiliser les objets consomm�s par la couche suivante, tu peux les g�rer dans un pool en marquant l'objet consomm� "dirty" quand il a �t� utilis�, et en ne le r�initialisant que quand c'est n�cessaire, c'est-�-dire quand ta couche de lecture en r�quisitionne un.

[Feriaman]

Tout d'abord, merci pour vos r�ponses.

Est-ce un cas d'�tude, ou as-tu un r��l probl�me de performance ?

As-tu un r�el probl�me de performances ?

Oui, j'ai en effet des probl�mes de performances, dans le sens ou je charge les fichiers moins vite que d'autres logiciels lisant les m�me donn�es (mais chaque logiciel ne lit qu'un seul format).
J'ai chronom�tr� les diff�rentes phases et l'amoindrissement des performances est en grande partie du au fait que j'utilise un mod�le interm�diaire. Ceci dit, je ne peux pas m'en passer, j'essaie donc de raboter o� je peux.

La plupart des compilateurs optimisent correctement la copy des PODs.
Regrouper tes variables membres de type simple dans une structure permettra s�rement de les copier bit � bit. Il faudrait test� n�anmoins, le gain de rapidit� entre la copie successibe de chaque membre de type simple et celle d'une structure englobante.

Je vais faire �a, c'est un bon point de d�part.

Ce que je ne comprends pas en revanche c'est l'inter�t de regrouper les types 'complexes' dans une seconde structure.

Bonne question.
Je suppose que ma structure SDonneesAlternativesDuCapitaine, n'a pas vraiment besoin de ces donn�es-l�, et donc ce n'est pas n�cessaire de les factoriser.
Bien vu.

Attention n�anmoins en subsituant l'appel d'une fonction de r�initialisation par celui d'un constructeur de copie. S'il y a allocation m�moire, il y aura n�cessairement un surco�t � moins de passer par un 'placement new'.

En effet, il serait plus malin de surcharger et d'utiliser l'op�rateur d'assignation afin d'�viter de perdre du temps � instancier un nouvel objet.

Plut�t que de r�utiliser toujours le m�me objet pour la lecture, construits-en un nouveau.

A l'arriv�e, et � moins que tu ne sois � une instruction machine pr�s, je te conseille de cr�er un objet � chaque fois.

L� par contre, je ne vois pas ce que j'y gagne. Nouveau ou pas, mon objet devra �tre initialis� non ? Qui plus est je crois qu'il est plus rapide d'utiliser un objet de la pile qu'un objet du tas.
Peux-tu �tre plus explicite sur le gain que j'aurais � c�truire l'ancien objet / cr�er un nouveau ?

Ou alors, si tu tiens vraiment � r�utiliser les objets consomm�s par la couche suivante, tu peux les g�rer dans un pool en marquant l'objet consomm� "dirty" quand il a �t� utilis�, et en ne le r�initialisant que quand c'est n�cessaire, c'est-�-dire quand ta couche de lecture en r�quisitionne un.

Hum ... de plus en plus flou.
En r�alist�, les op�rations se d�roulent s�quentiellement :
- la premi�re couche remplit un objet interm�diaire
- la seconde le traduit
- la premi�re couche re-remplit l'objet interm�diaire
- la seconde le re-traduit
- etc.
Sauf que, les objets n'�tant pas tous du m�me type, j'en ai un par type.
Je ne sais pas si je suis clair.

Quoi qu'il en soit, un gestionnaire d'objet et un flag dirty me semblent inutiles, puisqu'au moment o� je remplis un objet interm�diaire, il est forc�ment d�j� "dirty" sauf la premi�re fois.