Discussion :

[StephaneP]

Bonjour à tous,

J'ai un joli soft en open source que j'aimerais modifier.

Il fait appel à de nombreux fichiers de "config" qu'il lit via un fscanf en boucle. Au final, le soft prend environ 0.2 seconde en temps d'exécution.

Après quelques tests d'optimisation (En chargeant un fichier dans un tableau en mémoire par une lecture brute d'un fichier de config), je gagne facilement 50% de performance.

La prochaine étape, à mon sens, pour optimiser au mieux, serait de stocker ces données dans une DB, de préférence SQL Server, Hyperfile ou Mysql.

De quelles bibliothèques ai-je besoin pour me connecter à l'une de ces DB (Les infos pour chacune d'entre elle m'intéresse, afin de tester les performances de chacune d'entre elle pour mon application).

Quelqu'un dispose-t-il de bonne références/exemples? dur de trouver quelque chose de concret sur google.

Pour info, je développe avec VS 2005, et j'ai SQL Server 2005, Mysql 4.1 et Hyperfile pour windev 14.

Merci d'avance,

S.

[Mac LAK]

MySQL est par exemple fourni avec une librairie d'interface (API) directement utilisable sous Visual Studio, et il y a pas mal d'exemples dans la doc.
Pour SQL Server, il faut fouiller MSDN. Hyperfile, je n'ai jamais utilisé.


Par contre, en hors-sujet : pourquoi optimiser à ce point pour une durée d'exécution initiale aussi faible que 0.2 secondes ? Juste pour t'entrainer, ou tu as un but derrière ?
Parce que lancer une BD complète pour gagner, au final, très peu de temps par rapport à une lecture en RAM, c'est peut-être disproportionné... Et tu ne gagneras pas forcément autant que tu ne le penses, en plus.

[StephaneP]

Merci pour la réponse, je vais creuser déjà pour ces deux là. Reste Hyperfile...

Sinon, pourquoi optimiser à ce point? La réponse est simple, je travaille sur des séquences d'ADN, et l'ensemble du logiciel demande un nombre impressionnant de comparaisons et d'accès à ces valeurs fixes (pour au final calculer des Tm et des dG) qui se chiffrent en dizaine de milliers de comparaisons par run de l'application.

0.2 * 10000 = 2000 secondes (Temps d'exécution original)
0.075 * 10000 = 750 secondes (Temps d'exécution après optimisation sans DB)

Donc tout gain est appréciable dans ce genre d'application et à terme, ça sera un facteur crucial.

Bonne journée,

Stephane

[nicolas.sitbon]

Au vue des optimisations déjà effectués, je doute que tu gagnes quoique ce soit à utiliser une base de données. Je serais plutôt d'avis que tu nous montres ton code afin de voir ensemble les goulôts d'étranglements de ton programme (processeur, bus, cache, etc).

[Mac LAK]

Mmmm... Tu es ouvert à toutes formes de suggestion côté optimisation, sans toutefois tomber dans le "hack-à-Tonton-Marcel-tout-crade" ?

Il faudrait savoir combien de données sur disque tu as, quel est leur principe d'organisation et leur taille totale, pour commencer.
Il faut voir aussi si ton algo est parallélisable, et sur quelle portion minimale des données c'est possible.
N'oublie pas non plus qu'une BD, c'est complexe, et l'utiliser coûte du temps machine... Il est possible, au vu de tes chiffres, que tu perdes du temps à en utiliser une !!

Après, tu peux faire des choses comme câbler une BD "SQLite" montée en RAM exclusivement, et/ou pré-charger les données en modifiant leur organisation pour l'adapter à l'algorithme, utiliser tous les cœurs de ton CPU, etc. Parfois, optimiser un algo, c'est jeter l'ancien et repartir suivant un angle totalement différent, il faut en être conscient.

Une fois l'algo bien optimisé, un coup de profiling dessus (dépendant de la machine d'exécution finale, attention...) afin de traquer les dernier goulets d'étranglement vicieux, et ça devrait être pas mal.

[StephaneP]

Bonjour,

Tout d'abord, mettre le code source complet ici, ça serait impensable, c'est très complexe. Par contre, j'ai déjà identifié les goulets d'étranglement au niveau des perfs, et c'est uniquement, dans le programme original, 4 fonctions qui font des fscanf.

Voici un exemple d'une fonction originale (qui prend à elle seule 0.07 s en moyenne du temps d'exécution) et juste après la version modifiée (qui prend environ 0.04 s) :

Version originale :

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
33
34
35
36
37
38
39
void loadSint4(double sint4Energies[6][6][4][4][4][4], double sint4Enthalpies[7][7][5][5][5][5], int NA, double saltCorrection, double* gArray, size_t gArraySize, double* hArray, size_t hArraySize)
{
	int b, c, i1, j1, i2, j2;
 
	if (NA)
	{
		gFile = openFile("sint4.DGD");
		hFile = openFile("sint4.DHD");
	}
	else
	{
		gFile = openFile("sint4.DG");
		hFile = openFile("sint4.DH");
	}
 
	for (b = 0; b < 7; ++b)
		for (c = 0; c < 7; ++c)
			for (i1 = 0; i1 < 5; ++i1)
				for (j1 = 0; j1 < 5; ++j1)
					for (i2 = 0; i2 < 5; ++i2)
						for (j2 = 0; j2 < 5; ++j2)
							if (b == 6 || c == 6)
							{
								sint4Enthalpies[b][c][i1][j1][i2][j2] = INFINITY;
							}
							else if (i1 == 4 || j1 == 4 || i2 == 4 || j2 == 4)
							{
								sint4Enthalpies[b][c][i1][j1][i2][j2] = 0;
							}
							else
							{
								fscanf(gFile, "%lf", &sint4Energies[b][c][i1][j1][i2][j2]);
								sint4Energies[b][c][i1][j1][i2][j2] += 3.0 * saltCorrection;
								fscanf(hFile, "%lf", &sint4Enthalpies[b][c][i1][j1][i2][j2]);
								l++;
							}
	fclose(gFile);
	fclose(hFile);
}

Version modifiée :

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
void loadSint4(double sint4Energies[6][6][4][4][4][4], double sint4Enthalpies[7][7][5][5][5][5], int NA, double saltCorrection, double* gArray, size_t gArraySize, double* hArray, size_t hArraySize)
{
	int b, c, i1, j1, i2, j2, l = 0;
 
	for (b = 0; b < 7; ++b)
		for (c = 0; c < 7; ++c)
			for (i1 = 0; i1 < 5; ++i1)
				for (j1 = 0; j1 < 5; ++j1)
					for (i2 = 0; i2 < 5; ++i2)
						for (j2 = 0; j2 < 5; ++j2)
							if (b == 6 || c == 6)
							{
								sint4Enthalpies[b][c][i1][j1][i2][j2] = INFINITY;
							}
							else if (i1 == 4 || j1 == 4 || i2 == 4 || j2 == 4)
							{
								sint4Enthalpies[b][c][i1][j1][i2][j2] = 0;
							}
							else
							{
								sint4Energies[b][c][i1][j1][i2][j2] = gArray[l];
								sint4Energies[b][c][i1][j1][i2][j2] += 3.0 * saltCorrection;
								sint4Enthalpies[b][c][i1][j1][i2][j2] = hArray[l];
								l++;
							}
}

Et voici la fonction générique de lecture du fichier/parsing et mise en mémoire dans un tableau :

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
33
34
35
36
37
38
39
40
41
42
size_t loadSettings(int NA, char* filename, double* dataArray)
{
	int arraySize = 0;
	char finalFilename[255] = "";
	int gCurrentMaxSize = 20;
	char *buffer = NULL;
	FILE *pInFile = NULL;
	char **tab;
	size_t str_length = 0;
	int i, j, k;
 
	strcat(finalFilename, filename);
	if (NA)
	{
		strcat(finalFilename, "D");
	}
 
	i = 0;
	k = 0;
	pInFile = openFile(finalFilename);
	while(!feof(pInFile))
	{
		buffer = (char*)malloc(150);
		fgets(buffer, 150, pInFile);
		tab = split(buffer, "\t", 0);
		for (j = 0;tab[j];j++)
		{
			if (((k + 1) * sizeof(double)) > (gCurrentMaxSize * sizeof(double)))
			{
				gCurrentMaxSize += 50;
				dataArray = (double *)realloc (dataArray, gCurrentMaxSize * sizeof(double)); 
			}
			dataArray[k] = atof(tab[j]);
			k++;
		}
		free(tab);
		i++;
	}
	if (k > 0) arraySize = k - 1;
	free(buffer);
	return arraySize;
}

Il faut savoir que dans la version modifiée, gArray et hArray sont initialisées dans le main par une fonction générique qui va lire les fichiers (.DG* & .DH*) en bulk et stocke le tout dans un tableau en mémoire. Le gain de performance inclus la génération des deux tableaux.

Pour info, les fichiers concernés comportent 576 lignes contenant chacune 16 valeurs séparées par un tab, pour un total de 9216 valeurs à lire.

Le seul endroit qui consomme réellement beaucoup de temps processeur est le fscanf dans la version originale et la lecture du fichier dans la version modifiée.

Il est peut-être encore possible d'optimiser la fonction de lecture du fichier.

Il faut aussi savoir que chacune des fonctions qui consomme du temps processeur va lire 2 fichiers (.DG* & .DH*), certains comprennent quelques dizaines ou centaines de valeurs (Dans ce cas, le fscanf ne nuit pas aux perfs) d'autres plusieurs milliers.

Mon idée était de tester les perfs en chargeant les données non pas des fichiers mais directement à partir d'une DB, en faisant une requête qui retournerait l'équivalent du fichier valeur/ligne par valeur/ligne.

Si vous avez d'autres suggestions, je suis ouvert à toute proposition.

Merci de votre temps et de vos conseils.

Stephane

[StephaneP]

Et oui, je préfère éviter toute forme de "hack-à-Tonton-Marcel-tout-crade" parce l'application doit rester 100% fiable & bug free (Le monde idéal, quoi) mais je ne suis pas contre les tester, pour estimer le gain % au risque.

Sinon, j'avais pensé à SQLite mais j'ai oublié de poser la question pour la connexion C/SQLite...a voir ce que ça peut donner.

Pour le profiling en C, que conseillez-vous? J'utilise ANTS Performance Profiler en C# mais je n'en ai jamais utilisé en C. (A vrai dire, j'ai fait très peu de C ces dernières années, ça remonte quasi à l'époque où j'étais étudiant, ce qui ne me rajeunit pas... )