Discussion :

[Michael Guilloux]

Est-ce toujours plus rapide d'exécuter des opérations dans la mémoire des machines ?
Non, selon une étude

L'une des préoccupations majeures pour un développeur est de pouvoir livrer des logiciels qui offrent des performances adéquates pour les différentes opérations à exécuter. Même pour un informaticien « occasionnel », il est évident que l'accès répété au disque peut dégrader considérablement la performance de son logiciel en termes de temps d'exécution des opérations.

Depuis plusieurs années - surtout avec l'avènement des domaines d'application informatique tels que le High Performance Computing, le Big Data, et le BI - les développeurs ont été en quête de nouvelles possibilités d'accroître la vitesse de traitement de leurs applications. L'informatique in-memory ou en mémoire a donc contribué à la réalisation de cet objectif.

L'informatique in-memory désigne en fait le stockage de l'information dans la mémoire RAM des machines plutôt que d'opter pour des accès fréquents au disque, qui ont tendance à ralentir considérablement l'exécution des opérations.

Les opérations en mémoire comprennent notamment la mise en cache d'innombrables quantités de données en permanence. Cela garantit des temps de réponse extrêmement courts pour les recherches. Pour les sites web encore, elles offrent la possibilité de stocker les données de session pour une performance optimale du site.

La tradition recommande donc aux développeurs de minimiser l'accès au disque en effectuant autant que possible le travail en mémoire, pour bénéficier de temps d'exécution plus courts. Mais, est-ce toujours plus rapide d'exécuter des opérations dans la mémoire des machines ? Non, selon une étude réalisée par des chercheurs des universités de Calgary et de British Columbia.

Pour le démontrer, les chercheurs ont effectué des expériences en supposant dès le départ que les traitements en mémoire préalables avant écriture sur le disque garantissent des temps d'exécution plus courts que les écritures répétées sur le disque.

L'idée est d'écrire un programme qui génère des données et de les enregistrer dans un fichier. Leur exemple consistait à créer une chaîne de caractères de 1Mo et de l'écrire sur le disque. Ils procèdent donc de deux manières différentes. La première consiste à effectuer au préalable les calculs en mémoire avant d'inscrire le résultat en une seule écriture sur le disque. La chaîne de 1Mo sera obtenue en concaténant des chaînes de tailles fixes. Par exemple, on peut obtenir la chaîne de 1Mo en concaténant 1.000.000 chaînes de 1 octet, ou en concaténant 100.000 chaînes de 10 octets, ou encore en concaténant 1.000 chaînes de 1000 octets. Les concaténations sont faites en mémoire et le résultat est inscrit sur le disque.

La deuxième méthode consiste à écrire les chaînes directement sur le disque, ce qui implique des accès répétés sans calculs en mémoire au préalable. Les données sont donc générées en petits morceaux et enregistrées immédiatement sur le disque.

Les programmes sont écrits en Java et Python et testés sous Windows et Linux. Dans chaque cas, ils ont mesuré le temps qu'il faut pour terminer l'opération pour pouvoir faire des comparaisons entre les deux méthodes.

Dans le cas in-memory, le temps d'exécution est la somme du temps mis pour effectuer les calculs en mémoire et du temps mis pour enregistrer le résultat sur le disque. Dans l'approche d'écritures répétées sur le disque, il n'y a pas d'opération en mémoire, donc on mesure uniquement le temps nécessaire pour effectuer les écritures sur disque.

Les résultats montrent que pour le programme en Java, sous Windows comme sous Linux, les accès répétés au disque donnent de meilleurs temps d'exécution pour les différentes tailles de chaînes fixées. Les résultats sont donnés dans les tableaux ci-dessous:

Pour le programme en Python, les expériences sous Linux montrent que lorsque le nombre de concaténations augmente, les opérations en mémoire semblent donner de meilleurs temps d'exécution. Mais sous Windows, les accès répétés au disque sont plus efficaces que les opérations en mémoire. Les résultats sont donnés dans les tableaux ci-dessous:

« Bien que dans de nombreux cas, les opérations en mémoire sont plus rapides qu'un algorithme équivalent qui accède au disque, les contre-exemples présentés, basés sur la vie réelle montrent que ce n'est pas toujours le cas ,» ont écrit les chercheurs.


Ces derniers notent aussi que de petits changements de code peuvent avoir des effets dramatiques sur les temps d'exécution. Ils sont en effet parvenus à exécuter la version in-memory du code Python plus vite sous Linux en changeant l'ordre de concaténation des chaines. Ce changement de code sous Windows n'a cependant pas amélioré le temps d'exécution. Ils concluent alors que ce qu'il faut pour améliorer la vitesse de travail en mémoire, c'est de savoir comment le système d'exploitation et le langage gèrent les opérations. Ils suggèrent donc qu'une connaissance du système et de meilleures pratiques de programmation sont nécessaires pour assurer que les opérations en mémoire puissent atteindre leur plein potentiel.


Source : When In-Memory Computing is Slower than Heavy Disk Usage (pdf)

Et vous ?

Que pensez-vous des résultats de cette recherche ?

S'accordent-ils avec la réalité ?

Mise à jour

Après avoir analysé l'étude, certaines personnes ont reporté qu'il y aurait des erreurs dans le code Java. Ce qui pourrait fondamentalement biaiser les résultats, du moins, pour le langage Java.

[Médinoc]

Cette étude a été démontée sur le forum du Daily WTF quand un lecteur s'est rendu compte que la version "mémoire" de la concaténation de chaîne utilisait la concaténation Java, qui ré-alloue une nouvelle String à chaque fois, copiant le contenu de la précédente et ajoutant le nouveau caractère. En gros, d'après ledit lecteur tout le test s'effondre sur une erreur de String contre StringBuilder.

[Bono_BX]

Ils concluent alors que ce qu'il faut pour améliorer la vitesse de travail en mémoire, c'est de savoir comment le système d'exploitation et le langage gèrent les opérations. Ils suggèrent donc qu'une connaissance du système et de meilleures pratiques de programmation sont nécessaires pour assurer que les opérations en mémoire puissent atteindre leur plein potentiel.

Conclusion : on conclue que l'on ne sait rien. Utilité de l'étude ?

Je ne suis pas de ceux qui pensent que "on ne peut pas gérer finement la mémoire avec des langages comme JAVA", mais quand même, pour ce genre d'étude, le C me semble bien plus indiqué.

Ils sont en effet parvenus à exécuter la version in-memory du code Python plus vite sous Linux en changeant l'ordre de concaténation des chaines.

Je n'ai pas lu le détail de l'étude, mais cette remarque me fait furieusement penser à du Green IT, pas vous ?

[Voyvode]

Je viens de regarder le code. Il y a aussi un autre problème avec cette étude (en Java du moins) : les opérations prétendument disk-only sont faites avec des BufferedWriter.

Dans ce cas, c’est justement grâce à la mémoire que les écritures fréquentes sur le disque ont l’air si rapides.


[EDIT] Après vérification, Python utilise par défaut le système de cache de l’OS avec la commande open. Même topo donc.

[JackJnr]

Du coup si je comprends bien, ces chercheurs sont de futurs chercheurs... d'emploi !

--> [] !

[Washmid]

Cette étude a été démontée sur le forum du Daily WTF quand un lecteur s'est rendu compte que la version "mémoire" de la concaténation de chaîne utilisait la concaténation Java, qui ré-alloue une nouvelle String à chaque fois, copiant le contenu de la précédente et ajoutant le nouveau caractère. En gros, d'après ledit lecteur tout le test s'effondre sur une erreur de String contre StringBuilder.

Heu... C'est peut être une option d'optimisation mais "a" + "b" + "c" en code java utilise StringBuilder à l'exécution (eclipse, config par défaut, il suffit d'exécuter en pas-à-pas pour le constater).

[Voyvode]

@Washmid
C’est vrai uniquement avec les concaténations simples. Le compilateur sait optimiser "a" + "b" + "c" sans problème.

Dans une boucle, en revanche, un StringBuilder est plus que recommandé. C’est exactement ce qu’ils n’ont pas fait dans leurs tests.

[bigjeff]

Bonjour,

En lisant l'article j'ai été surpris des résultats, j'ai repris le code qui est dans lien. J'ai été surpris de voir que la concaténation (en Java) se faisait avec la classe String et + pour concaténer.

J'ai repris le code, j'ai crée 2 classes une pour le test en mémoire puis écriture et l'autre pour l'écriture directe afin que le deuxième cas ne récupère pas les gains d'optimisation de la JVM du premier cas.

À la place de la classe String j'ai testé StringBuilder puis StringBuffer et les résultats sont tout autre, j'ai réduit la zone mémoire à 100 000 au lieu de 1 000 000 afin que cela s'exécute plus vite sur mon PC. Voici les résultats :

La concaténation en mémoire :
Avec String et +: 2.7836 secondes
Avec StringBuffer et append : 0.00279 seconde
Avec StringBuilder et append : 0.0016 seconde

Les résultats d'écriture disque sont à peu près égaux à l'étude initiale.

Côté Python je n'ai pas assez de connaissance mais en Java il vaut mieux travailler en mémoire.

Peut-être que je me trompe.

[Washmid]

@Voïvode : Ha, oui, effectivement, si on concatène pas sur la même ligne ça marche pas, autant pour moi, merci ^^

[MikeRowSoft]

A vraie dire, la mémoire cache des CPU qui sont actuellement utilisé dans le commerce ne sont pas vraiment les plus rapides, pourtant il y en a peu. Pour resté humble, les cartes graphiques s'en sortent pourtant très bien malgré la lenteur toutes relatives de leurs mémoires.

[De Bain]

Une petite recherche sur Google Scholar et on voit que l'article n'a jamais été publié dans une revue ou une conférence scientifique (et donc jamais été relu par d'autres scientifiques). Il s'agit seulement d'une soumission à une plateforme d'hébergement et de référencement d'articles.

C'est n'est pas "une étude scientifique", c'est "un papier écrit par 3 scientifiques qui personne n'a relu", ca n'a pas plus de valeur scientifique qu'un billet de blog.

[agodfrin]

L'étude est intéressante et mérite mieux que les moqueries sur la mauvaise façon de concaténer des chaines en java. En fait la conclusion est précisément que le simple fait de réécrire des algorithmes de façon à utiliser davantage de calculs en mémoire sur de grosses structures de données (en limitant les accès disque) n'est pas toujours une garantie de succès.

La concaténation en Java qui prend plus de temps que des accès disque répétés le démontre de manière un peu forcée: selon la technique utilisée une opération peut prendre considérablement plus ou moins de temps (exemple de la concaténation simple en java vs Stringbuilder). De même les opérations sur disque sont de nos jours optimisées de plein de façons (entre les BufferedXxx de Java, les diverses caches du file system, les diverses caches des contrôleurs, et même les caches des disques ou des SSDs). C'est ce que l'étude montre par l'absurde et de manière artificielle.

On peut aussi extrapoler sur les requêtes SQL sur une base de données: on peut donner à la base une quantité considérable de mémoire (genre 256GB de RAM) que la base va s'empresser d'utiliser pour ses buffers. De ce fait tout un tas de requêtes peu optimisées vont aller plus vite du fait de l'absence d'I/Os. Mais le fait d'avoir 100% de "buffer cache hits" ne veut pas dire que les requêtes sont rapides et ne veut pas dire qu'on peut se passer d'index au bon endroit.

Le message final est que ce n'est pas parce qu'on a une resource en grande quantité (CPU, mémoire, ...) qu'il suffit d'implémenter n'importe quel algorithme simpliste ... C'est d'ailleurs vrai pour plein de choses: ce n'est pas parce qu'on a plein d'eau pas chère qu'il faut la gaspiller :-)

[Squisqui]

Sans même parler d'implémentation, le test est tellement peu représentatif de la réalité qu'on se dit qu'on est bien Vendredi

[iolco51]

Dans la plupart des tests Windows est deux fois plus lent que Linux, lorsque ce n'est pas le cas les performances sont à peu près équivalentes. C'est intéressant.

Sinon je ne comprends pas l'objectif du test, s'il s'agit d'écrire en séquentiel sur le disque alors c'est certain, pourquoi d'abord faire une concaténation en mémoire (ce qui signifie reallocations multiples) en concaténant des chaines alors qu'on peut écrire directement sur le disque, ce qu'il faudra faire de toutes façons. C'est une évidence.

Le test intelligent est d'utiliser des memory mapped files, d'y écrire en séquentiel et de laisser l'OS travailler. Utiliser les types strings du langage de programmation pour les concaténer ensemble au préalable n'a absolument aucun sens lorsque c'est une séquence à écrire telle quelle.

Cela se résume à : Est-ce que faire les operations 1,000,000 de fois en memoire et écrire sur disque est plus rapide que ne traiter qu'une seule fois et directement écrire sur disque.... La réponse est évidente.

[DarkHylian]

Euh, l'article est pas du tout à sa place : fallait le mettre dans la section Humour je crois bien...
Déjà, faut passer outre le code Java pas optimisé du tout (même bourré, n'importe qui d'initié au Java ferait mieux)

Ensuite le test fait en Java, rien que ça, c'est la plus mauvaise idée (ou alors c'est qu'on veut tester les perfs de JVM, mais dans ce cas, il faut tester les différentes versions).
Si on veut faire de la comparaison sur la gestion mémoire, au pire on prend du C, au mieux, on passe en assembleur (m'enfin ça, je le recommande que pour les plus chevronnés)

En plus de ça, comme test, Linux VS Windows... ça veut un peu rien dire : il faut pas oublier derrière qu'il y a le système de fichier, l'architecture matériel, et j'en passe.
Si on veut neutraliser ces effets : ben on peut pas en fait... chaque S.E. a sa façon de gérer un S.F. et chaque S.F. a sa façon de gérer les accès disques. Chaque matos a sa propre spécificité sur la façon d'accès aux données, etc.
Rien que sous linux, pour quasiment tous les S.F. on peut demander les accès asynchrones, auquel cas on squatte le cache jusqu'à l'écriture réelle. Sur certaine (vieille) bios, ou dans certaines config du S.E., on peut même demander à assigner une quantité de RAM en guise de cache pour les DD.

Ensuite, les accès disques, même s'ils étaient réellement plus rapide, il faut les limiter pour la longévité du disque lui-même. Un SSD est "limité" en écriture/ré-écriture, beaucoup plus qu'un HDD en tout cas. Mais même pour un HDD, trop de mouvements mécaniques sur nos bon vieux HDD peut aussi entraîner une mort anticipée. (D'ailleurs, ça me fait penser à une blague sur le point commun entre un HDD et un mec devant YouPron ... je vous laisse cogiter)

Bref, avoir pondu un pseudo article pour ça, faut être taré (ou ne pas savoir quoi faire de son temps).
S'ils veulent faire un travail complet, faut doser l'efficacité en terme d'exécution d'un coté, et la minimisation de l'usure du matos de l'autre. A ça, faut faire une étude comparative sur plus S.F., S.E. et architecture matériel.
En plus, il faudrait savoir la quantité d'énergie consommée pour chaque opération et par matos... mais à force, on sort du cadre..

Il me semble que au final, c'est la RAM qui gagne sur ce point là, puisqu'elle est vraiment prévu pour lecture/écriture/ré-écriture à des vitesses élevées, et avec des capacités de stockage de plus en plus élevées. A ca, on rajoute que les procos ont des caches de plus en plus grand, et que les S.E. sont généralement de plus en plus performant en termes de gestion de la RAM et des accès disques (un petit retard p e chez Windows, mais je mettrais pas ma main à couper)

Enfin, il faut pas perdre de vue que généralement, quand on fait des calculs en RAM, c'est pas pour écrire le résultat dans le DD juste après. Généralement, on affiche le résultat quelque part, ou on s'en ressert pour d'autres opération.
Ce test n'a de validité que si on considère que tous les résultats d'opérations doivent-être enregistrés sur mémoire de stockage.

Bon week end

[Traroth2]

Dans la plupart des tests Windows est deux fois plus lent que Linux, lorsque ce n'est pas le cas les performances sont à peu près équivalentes. C'est intéressant.

Sinon je ne comprends pas l'objectif du test, s'il s'agit d'écrire en séquentiel sur le disque alors c'est certain, pourquoi d'abord faire une concaténation en mémoire (ce qui signifie reallocations multiples) en concaténant des chaines alors qu'on peut écrire directement sur le disque, ce qu'il faudra faire de toutes façons. C'est une évidence.

Le test intelligent est d'utiliser des memory mapped files, d'y écrire en séquentiel et de laisser l'OS travailler. Utiliser les types strings du langage de programmation pour les concaténer ensemble au préalable n'a absolument aucun sens lorsque c'est une séquence à écrire telle quelle.

Cela se résume à : Est-ce que faire les operations 1,000,000 de fois en memoire et écrire sur disque est plus rapide que ne traiter qu'une seule fois et directement écrire sur disque.... La réponse est évidente.

C'est ce que je me suis dit aussi. En écrivant séquentiellement sur le disque, ils ont vraiment choisi une fonction qui a peut effectivement être plus rapide en écrivant directement tout sur le disque, puisque si on fait la concaténation en mémoire et qu'on écrit le résultat, l'opération d'écriture consistera effectivement en la même écriture séquentielle, en gros. Mieux vaut donc écrire tout de suite. Mais je pense que c'est un cas très particulier qu'on ne peut pas du tout généraliser. Et en plus, les résultats sont semble-t-il faussé par une utilisation totalement inadéquate des outils Java, ce qui biaise l'étude en faveur de l'exécution en opérant sur le disque.

[kolodz]

Après, quand tu lis le papier il y a des trucs qui choc :

Kamran Karimi¹, Diwakar Krishnamurthy², Parissa Mirjafari³
Dept of Biological Sciences ¹,
Dept of Electrical and Computer Engineering ²,
Dept of Chemical and Biological Engineering ³

En résumé, 2 chimistes et un électronicien...

Lecture au survole de la publication :

Appendix 1. However, using a mutable data type such as StringBuilder or StringBuffer dramatically improved the results.

Genre information secondaire ! Pas comme si l'ensemble de papier est basé dessus...


@bigjeff : Non non tu ne te trompe pas !
Voici mon test avec le code correspondant !

String + String (Version original)
Pas les temps beaucoup trop long sur ma machine !!!

Code java :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
// By Kamran Karimi (kkarimi@ucalgary.ca)
// Complete version. Runs each experiment 10 times
import java.io.IOException;
import java.io.FileWriter;
import java.io.BufferedWriter;
 
public class Test {
	public static void main(String[] args) {
		// number of increments for the file content.
		int numAdd = 1; // Additional changes are needed when NUM_ADD = 1e6
		int NUM_ITERATIONS = 10;
		long totalMemory = (long) 1000000; // total amount of memory in bytes
		String addString = "";
		for (int i = 0; i < numAdd; i++) {
			addString += "1";
		}
		double[] stringTimes = new double[NUM_ITERATIONS];
		double[] fileTimes1 = new double[NUM_ITERATIONS];
		double[] fileTimes2 = new double[NUM_ITERATIONS];
		for (int count = 0; count < NUM_ITERATIONS; count++) {
			stringTimes[count] = fileTimes1[count] = fileTimes2[count] = 0;
			BufferedWriter writer;
			// First part: in-memory
			long numIter = totalMemory / addString.length();
			String  concatString = "";
			long startTime = System.currentTimeMillis();
			for (int i = 0; i < numIter; i++) {
				concatString+=addString;
			}
			long endTime = System.currentTimeMillis();
			double stringTime = (endTime - startTime) / 1000.0;
			stringTimes[count] = stringTime;
			try {
				writer = new BufferedWriter(new FileWriter("test.txt"));
				startTime = System.currentTimeMillis();
				writer.write(concatString);
				writer.flush();
				writer.close();
				endTime = System.currentTimeMillis();
			} catch (IOException e) {
			}
			double fileTime = (endTime - startTime) / 1000.0;
			fileTimes1[count] = fileTime;
			// Second part: disk-only
			try {
				writer = new BufferedWriter(new FileWriter("test.txt"));
				startTime = System.currentTimeMillis();
				for (int i = 0; i < numIter; i++) {
					writer.write(addString);
				}
				writer.flush();
				writer.close();
				endTime = System.currentTimeMillis();
				fileTime = (endTime - startTime) / 1000.0;
				fileTimes2[count] = fileTime;
			} catch (IOException e) {
			}
		}
		double stringMean = 0;
		for (int i = 0; i < stringTimes.length; i++) {
			stringMean += stringTimes[i];
		}
		stringMean /= stringTimes.length;
		double fileMean1 = 0;
		for (int i = 0; i < fileTimes1.length; i++) {
			fileMean1 += fileTimes1[i];
		}
		fileMean1 /= fileTimes1.length;
		double fileMean2 = 0;
		for (int i = 0; i < fileTimes2.length; i++) {
			fileMean2 += fileTimes2[i];
		}
		fileMean2 /= fileTimes2.length;
		System.err.println("In-memory mean: string time" + stringMean);
		System.err.println("In-memory mean: file time " + fileMean1);
		System.err.println("In-memory mean: Total " + (fileMean1+stringMean));
		System.err.println("Disk-only mean: file time " + fileMean2);
	}
}

StringBuilder append
In-memory mean: string time0.020599999999999997
In-memory mean: file time 0.007000000000000001
In-memory mean: Total 0.0276
Disk-only mean: file time 0.0397

Code Java :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
// By Kamran Karimi (kkarimi@ucalgary.ca)
// Complete version. Runs each experiment 10 times
import java.io.IOException;
import java.io.FileWriter;
import java.io.BufferedWriter;
 
public class Test {
	public static void main(String[] args) {
		// number of increments for the file content.
		int numAdd = 1; // Additional changes are needed when NUM_ADD = 1e6
		int NUM_ITERATIONS = 10;
		long totalMemory = (long) 1000000; // total amount of memory in bytes
		String addString = "";
		for (int i = 0; i < numAdd; i++) {
			addString += "1";
		}
		double[] stringTimes = new double[NUM_ITERATIONS];
		double[] fileTimes1 = new double[NUM_ITERATIONS];
		double[] fileTimes2 = new double[NUM_ITERATIONS];
		for (int count = 0; count < NUM_ITERATIONS; count++) {
			stringTimes[count] = fileTimes1[count] = fileTimes2[count] = 0;
			BufferedWriter writer;
			// First part: in-memory
			long numIter = totalMemory / addString.length();
			StringBuilder  concatString = new StringBuilder ();
			long startTime = System.currentTimeMillis();
			for (int i = 0; i < numIter; i++) {
				concatString.append(addString);
			}
			long endTime = System.currentTimeMillis();
			double stringTime = (endTime - startTime) / 1000.0;
			stringTimes[count] = stringTime;
			try {
				writer = new BufferedWriter(new FileWriter("test.txt"));
				startTime = System.currentTimeMillis();
				writer.write(concatString.toString());
				writer.flush();
				writer.close();
				endTime = System.currentTimeMillis();
			} catch (IOException e) {
			}
			double fileTime = (endTime - startTime) / 1000.0;
			fileTimes1[count] = fileTime;
			// Second part: disk-only
			try {
				writer = new BufferedWriter(new FileWriter("test.txt"));
				startTime = System.currentTimeMillis();
				for (int i = 0; i < numIter; i++) {
					writer.write(addString);
				}
				writer.flush();
				writer.close();
				endTime = System.currentTimeMillis();
				fileTime = (endTime - startTime) / 1000.0;
				fileTimes2[count] = fileTime;
			} catch (IOException e) {
			}
		}
		double stringMean = 0;
		for (int i = 0; i < stringTimes.length; i++) {
			stringMean += stringTimes[i];
		}
		stringMean /= stringTimes.length;
		double fileMean1 = 0;
		for (int i = 0; i < fileTimes1.length; i++) {
			fileMean1 += fileTimes1[i];
		}
		fileMean1 /= fileTimes1.length;
		double fileMean2 = 0;
		for (int i = 0; i < fileTimes2.length; i++) {
			fileMean2 += fileTimes2[i];
		}
		fileMean2 /= fileTimes2.length;
		System.err.println("In-memory mean: string time" + stringMean);
		System.err.println("In-memory mean: file time " + fileMean1);
		System.err.println("In-memory mean: Total " + (fileMean1+stringMean));
		System.err.println("Disk-only mean: file time " + fileMean2);
	}
}

StringBuffer append
In-memory mean: string time0.037399999999999996
In-memory mean: file time 0.007000000000000001
In-memory mean: Total 0.044399999999999995
Disk-only mean: file time 0.041499999999999995

Code Java :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
// By Kamran Karimi (kkarimi@ucalgary.ca)
// Complete version. Runs each experiment 10 times
import java.io.IOException;
import java.io.FileWriter;
import java.io.BufferedWriter;
 
public class Test {
	public static void main(String[] args) {
		// number of increments for the file content.
		int numAdd = 1; // Additional changes are needed when NUM_ADD = 1e6
		int NUM_ITERATIONS = 10;
		long totalMemory = (long) 1000000; // total amount of memory in bytes
		String addString = "";
		for (int i = 0; i < numAdd; i++) {
			addString += "1";
		}
		double[] stringTimes = new double[NUM_ITERATIONS];
		double[] fileTimes1 = new double[NUM_ITERATIONS];
		double[] fileTimes2 = new double[NUM_ITERATIONS];
		for (int count = 0; count < NUM_ITERATIONS; count++) {
			stringTimes[count] = fileTimes1[count] = fileTimes2[count] = 0;
			BufferedWriter writer;
			// First part: in-memory
			long numIter = totalMemory / addString.length();
			StringBuffer concatString = new StringBuffer ();
			long startTime = System.currentTimeMillis();
			for (int i = 0; i < numIter; i++) {
				concatString.append(addString);
			}
			long endTime = System.currentTimeMillis();
			double stringTime = (endTime - startTime) / 1000.0;
			stringTimes[count] = stringTime;
			try {
				writer = new BufferedWriter(new FileWriter("test.txt"));
				startTime = System.currentTimeMillis();
				writer.write(concatString.toString());
				writer.flush();
				writer.close();
				endTime = System.currentTimeMillis();
			} catch (IOException e) {
			}
			double fileTime = (endTime - startTime) / 1000.0;
			fileTimes1[count] = fileTime;
			// Second part: disk-only
			try {
				writer = new BufferedWriter(new FileWriter("test.txt"));
				startTime = System.currentTimeMillis();
				for (int i = 0; i < numIter; i++) {
					writer.write(addString);
				}
				writer.flush();
				writer.close();
				endTime = System.currentTimeMillis();
				fileTime = (endTime - startTime) / 1000.0;
				fileTimes2[count] = fileTime;
			} catch (IOException e) {
			}
		}
		double stringMean = 0;
		for (int i = 0; i < stringTimes.length; i++) {
			stringMean += stringTimes[i];
		}
		stringMean /= stringTimes.length;
		double fileMean1 = 0;
		for (int i = 0; i < fileTimes1.length; i++) {
			fileMean1 += fileTimes1[i];
		}
		fileMean1 /= fileTimes1.length;
		double fileMean2 = 0;
		for (int i = 0; i < fileTimes2.length; i++) {
			fileMean2 += fileTimes2[i];
		}
		fileMean2 /= fileTimes2.length;
		System.err.println("In-memory mean: string time" + stringMean);
		System.err.println("In-memory mean: file time " + fileMean1);
		System.err.println("In-memory mean: Total " + (fileMean1+stringMean));
		System.err.println("Disk-only mean: file time " + fileMean2);
	}
}

Winner is :
StringBuilder append avec 0.0276

Cordialement,
Patrick Kolodziejczyk.

[djuju]

Quel est la vitesse de la RAM utilisée? De la 1GHz? De la 2.4GHz? Single, dual ou quad channel ? Ca peut drastiquement changer le résultat du test.
Et le disque ? Un HDD 7200rpm ? Un SSD dernière génération Sata III ou un M2? Les résultats risquent d'être totalement différents selon le hardware utilisé.

En résumé, 2 chimistes et un électronicien...

Effectivement... En plus l'article semble venir de itword.com et non d'une conférence en info sérieuse.

[23JFK]

Ça marche!... Avec un système utilisant une mémoire à 8MHz et un hdd à 7200 RPM

[guillaume07]

tout à fait c'est comme lancer une application depuis un raccourci sur le desktopça donne des latences en terme d'I/O toujours un peu meilleur.