Discussion :

[moidibe]

Bonjour,

je suis en train de re-créer un programme qui doit faire beaucoup de calcul mathématique. (Le premier programme était beaucoup trop lent...)
On teste pour cela différentes valeurs de départ, quelques centaines de milliers en fait.
J'avais pensé utiliser la STL pour avoir une meilleur gestion de la mémoire mais je ne sais pas si c'est la meilleur possibilité.

Il faut que j'évite les allocations de mémoire et je ne vois pas trop comment m'en sortir. Sachant qu'à chaque nouvelle étape de calcul je dois generer (allocation) de nouvelles données mais si je tombe dans une impasse je dois revenir en arrière (suppression des données).
La mémoire nécessaire pour faire tourner le programme n'est pas très grande normalement donc je pourrais utiliser de la mémoire pré-alloué qui sera immédiatement disponible : Un buffer...
Comment bien gérer ce buffer ? avez-vous des conseils à me donner ?
Un exemple ?


Le temps de calculs est un paramètre important. L'objectif de la nouvelle version est de considérablement réduire le temps de calcul.

Je vous remercie d'avance.

[Invité]

Si le programme précédent fonctionne, et que son seul défaut est d'être lent, il faut commencer par comprendre ce qui le ralentit.

Utilises un profileur pour savoir où le temps de calcul est passé, et pars de ses résultats. Il est tout à fait possible que le problème ne vienne pas d'où tu penses. Si tu arrives à t'en sortir sans tout réécrire, tu vas gagner un temps précieux (surtout en mise au point). Si à la fin tu dois de toutes façons réécrire, les informations de profiling t'aideront à définir l'architecture de ta "v2".

Francois

[3DArchi]

Salut,
Le conseil de François me semble quand même de bon sens pour commencer une optimisation.
Si d'aventure, tu avais un problème à cause des allocations, alors intéresse toi aux allocateurs qu'acceptent les conteneurs et qui peuvent t'aider à avoir des gains sur ce point.

[moidibe]

Ok. Pour commencer, je vais suivre votre conseil et je vais éplucher le fichier du profileur.