Discussion :

[epsilon68]

Si t'utilises de la mémoire en trop c'est que tu t'y es mal pris...

merci pour le compliment, en meme temps, au début, je l'avais fait de la meme maniere qu'avec C#. apres je l'ai optimisé pour avoir un temps et un cout memoire inferieurs.

Le COW n'a d'intérêt que si tu copies alors que tu devrais pas, ou si tu as une mauvaise structure avec redondance des données.

justement je fais beaucoup de copies.

---

Maintenant, c'est tres dure de comparer deux programmes et j'essaie de les comparer avec le meme algo, donc le meme nombre de recopies etc.
c'est vrai je fais beaucoup de copies et c'est en ca que je suis decu de Qt, ca n'ameliore rien.

Ce que je tire de tout ca d'apres tes petites phrases laconiques et un tantinet ironiques, c'est que finalement mieux vaudrait un langage comme Java/C#, meme moyen, on arrive a de bonnes perfs avec un programme plus lisible

:/

[epsilon68]

... aussi il y avait une question / proposition dans mon post (celui presentant les resultats)

[JolyLoic]

Maintenant, c'est tres dure de comparer deux programmes et j'essaie de les comparer avec le meme algo, donc le meme nombre de recopies etc.
c'est vrai je fais beaucoup de copies et c'est en ca que je suis decu de Qt, ca n'ameliore rien.

Qui te dis que ta STL n'implémente pas aussi le COW sur les strings ?

[epsilon68]

Qui te dis que ta STL n'implémente pas aussi le COW sur les strings ?

j'ai utilisé la stl de Visual studio 2005, je ne sais pas si ca utilise le COW, je ne pense pas mais peut-etre peux-tu me le confirmer.
aussi, meme si ca utilise le cow, la version C++ avec map<string,....> etait completement dans les choux. Mais bon l'avantage du C++ c'est qu'il y a toujours moyen d'optimiser....

[JolyLoic]

j'ai utilisé la stl de Visual studio 2005, je ne sais pas si ca utilise le COW, je ne pense pas mais peut-etre peux-tu me le confirmer.

Je viens de jetter un oeil dans le code, et elle n'a pas l'air de l'utiliser. Ce qui change par rapport à VC6, je crois.

aussi, meme si ca utilise le cow, la version C++ avec map<string,....> etait completement dans les choux. Mais bon l'avantage du C++ c'est qu'il y a toujours moyen d'optimiser....

As-tu moyen de poster le code en question quelquepart, qu'on sa fasse une idée du genre de choses faites, au moins la version non optimisée ?

[epsilon68]

As-tu moyen de poster le code en question quelquepart, qu'on sa fasse une idée du genre de choses faites, au moins la version non optimisée ?

il faut que je regarde comment je pourrais le transformer pour le rendre anonyme. Ca va etre difficile... c'est aussi pour ca que je proposais de programmer tous ensemble une appli de ce genre, pas trop importante en temps comme une transformation de fichier ?! et on l'implemente dans plusieurs langages ...

[epsilon68]

... programmer tous ensemble une appli de ce genre, pas trop importante en temps comme une transformation de fichier ?! et on l'implemente dans plusieurs langages ...

Qu'en pensez-vous ?
une sorte de concours ou il faut etre le plus rapide a l'execution

[JolyLoic]

J'ai peur de ce genre de "concours". Je préfèrerais un concours de ce genre, mais où le but n'est pas d'être rapide, mais de maximiser le ratio "simple à écrire/rapidité" (le premier élément étant difficilement mesurable). Après tout, en rapidité pure, surtout pour un test de petite taille, on aura du mal à battre l'assembleur et les appels directs au système, même si on sait que ce n'est pas scalable.

[Jean-Marc.Bourguet]

Ça me rappelle quelque chose... il me semblait qu'on a ouvert un forum pour ce genre de concours mais je ne le retrouve pas.

Si tu donnes une spec, je m'y lancerai peut-être. Mais ma jambe est guérie donc je n'ai plus le temps que j'avais quand j'étais forcé de rester chez moi.

[Jean-Marc.Bourguet]

J'ai peur de ce genre de "concours". Je préfèrerais un concours de ce genre, mais où le but n'est pas d'être rapide, mais de maximiser le ratio "simple à écrire/rapidité" (le premier élément étant difficilement mesurable). Après tout, en rapidité pure, surtout pour un test de petite taille, on aura du mal à battre l'assembleur et les appels directs au système, même si on sait que ce n'est pas scalable.

Je crois qu'apres un peu d'optimisation on va remarquer que les differences sont dans les bruits des IO. C'etait ma conclusion sur l'exemple du tri qui avait ete propose.

[Matthieu Brucher]

Ça me rappelle quelque chose... il me semblait qu'on a ouvert un forum pour ce genre de concours mais je ne le retrouve pas.

[info]Il a été mis en attente de recentrage.[/info]

[epsilon68]

J'ai peur de ce genre de "concours". Je préfèrerais un concours de ce genre, mais où le but n'est pas d'être rapide, mais de maximiser le ratio "simple à écrire/rapidité" (le premier élément étant difficilement mesurable). Après tout, en rapidité pure, surtout pour un test de petite taille, on aura du mal à battre l'assembleur et les appels directs au système, même si on sait que ce n'est pas scalable.

je suis d'accord alors il faut un jury et argumenter ses choix.

[epsilon68]

que proposez-vous ?
une transformation de fichier ?
je peux reflechir a un truc comme ca...

[loufoque]

Commence par fournir ton code qu'on puisse t'expliquer pourquoi il est lent et utilise trop de mémoire.

[epsilon68]

le probleme c'est que mon code est utilisé professionnellement et je ne tiens pas a le voir partout .... tu comprends ?
c'est pour ca que j'aimerais le faire sur un truc semblable du meme genre ...