Discussion :

[Clad3]

Bonjour, j'ai un code que je trouve d'une lenteur abominable, mais je ne comprend pas pourquoi . Je dois créer deux double tableau de dimension 2048*2048 . Je procède ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	StringPixel.resize(I.Largeur);
	Traite.resize(I.Largeur);
	for (unsigned int i = 0 ; i < I.Largeur ; i ++ )
	{
		StringPixel[i].resize(I.Hauteur);
		Traite[i].resize(I.Hauteur);
 
		for ( unsigned int j = 0 ; j < I.Largeur ; j++)
		{
			StringPixel[i][j] = "" ;
			Traite[i][j] = false ;
		}
	}

Ce code met plus de 1 minutes ( je me suis arreter a une minute, il est possible qu'il mette bien plus) pour s'éxécuter ! ( ~5 seconde sans la seconde boucle ). Ca me parait énorme, ou alors je ne m'y rpend pas correctement?

[ J'envisagerai d'utiliser des tableaux statiques, mais pour le principe je me demande pourquoi c'est si lent avec des vector ]

EDIT : Simplment la déclaration de bool B[2048][2048] fait planter le prog a l'éxécution, sur une machine de 1go de ram c'est nromal ? (je vais prendre ma calculette pr voir ca :p )

EDIT 2: Probleme résolu a priori, je suis passé en mode "Release" au lieu de "Debug", et ca va toute de suite mieux.

[Bakura]

En effet c'est pas censé être si long .

Il y a sûrement moyen de faire mieux, les gurus du forum vont sûrement de donner les techniques, mais perso je propose ça :

std::vector <std::vector <std::string> > tab (2048);

for (std::vector<std::string>::size_type t = 0 ; t != tab.size() ; ++t)
{
tab.at(t).resize (2048);
}

Sinon, un vector de bool c'est déconseillé pour des raisons que je ne me souviens plus, mais les autres vont sûrement t'expliquer .

EDIT alors : 1.156 seconde en mode debug.
EDIT 2 : et 0.250 seconde en mode release. Je pensais pas que la différence était si grande , qu'est-ce que release fait de plus ?

[loufoque]

Si T est ton type contenu dans ta structure std::vector<std::vector<T> >, alors tu fais une allocation de 2048*sizeof(std::vector<T>) octets + 2048 allocations de 2048*sizeof(T) octets.
Alors qu'en fait, il te suffirait d'allouer une fois 2048*2048*sizeof(T) octets.

EDIT : Simplment la déclaration de bool B[2048][2048] fait planter le prog a l'éxécution, sur une machine de 1go de ram c'est nromal ? (je vais prendre ma calculette pr voir ca :p )

La pile a généralement une taille fort limitée.

Donc tu peux faire ça de plusieurs façons :
std::vector<T> v(2048*2048), puis quand tu veux accéder à v[i][j] en fait tu fais v[i * 2048 + j]
ou alors, plus simple,
std::vector<std::array<T, 2048> > v(2048) et tu peux directement écrire v[i][j].
ou alors, éventuellement,
boost::multi_array<T, 2> v(boost::extents[2048][2048]); et tu peux là aussi écrire v[i][j].

[Clad3]

Merci, je voios bien l'enjeu du problème ! je laiss en on réoslu si quelqu'un peux renseigner Bakura sur els différence degub/release, je dirai ( à prendre avec des pincettes) que c'est propre au compilateur et que celui-ci ajoute aps mal d'information à ton code te permetttant de debugger le tout plus tard .

[loufoque]

Il y a sûrement moyen de faire mieux, les gurus du forum vont sûrement de donner les techniques, mais perso je propose ça :

std::vector <std::vector <std::string> > tab (2048);
// puis un resize à chaque itération

Code :

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

std::vector<std::vector<std::string> > tab(2048, std::vector<std::string>(2048));

[Sylvain Togni]

Code :

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

std::vector<std::vector<std::string> > tab(2048, std::vector<std::string>(2048));

C'est plus court à écrire mais bien plus long à l'exécution (copie de 4 millions de string en plus).