Connaitre la machine c'est bien, mais pas indispenssable.
Par contre, connaitre les structures de données qu'on utiliser, c'est indispensable: les plus gros gains de perf se font sur l'algorithmique.
Sinon, j'ai pas envie de passer ma vie à optimiser, mais je préfère développer des fonctionnalité à temps, tout simplement parce que je ne dispose pas d'un temps infini. Donc je ne veux pas être obligé de gérer la taille des entiers , les float, double & co: il faut savoir s'arrêter. De plus ce genre d'optimisation n'est souvent pas portable, et générateur de bug.
Je préfère un langage/lib qui m'expose des types de plus haut niveau, ce qui ne dispense pas d'être implémenté de manière performante.
Donc en résumé, ce que tu dis peut s'appliqué pour ceux qui écrivent des lib en C, s'ils savent ce qu'il font. Pour les autres je conseille de s'appliquer sur le fonctionnel et la validité de leur code: avoir rapidement un résultat faux (ou un plantage), ça sert à rien.
Pour les Vector et Hashtable, il ne sont pas deprecated à ma connaissance, ms devraient surement l'être, voir même suprimés. Je justement attirer l'attention sur le fait que beaucoup de dev java ne connaissent que ces structure de données qui sont synchronisées par défaut, ce qui bouffe de perf, alors que bien souvent on en a pas besoin. Il faudrait les supprimer (ou déprécier si on veut garder la compatibilité) car il existe d'autres moyens pour synchoniser une collection, et ça ne simplifie pas l'api.
[^] # Re: Plop !
Posté par パパフラクス . En réponse au journal "L'informatique Paradoxale". Évalué à 5.
Par contre, connaitre les structures de données qu'on utiliser, c'est indispensable: les plus gros gains de perf se font sur l'algorithmique.
Sinon, j'ai pas envie de passer ma vie à optimiser, mais je préfère développer des fonctionnalité à temps, tout simplement parce que je ne dispose pas d'un temps infini. Donc je ne veux pas être obligé de gérer la taille des entiers , les float, double & co: il faut savoir s'arrêter. De plus ce genre d'optimisation n'est souvent pas portable, et générateur de bug.
Je préfère un langage/lib qui m'expose des types de plus haut niveau, ce qui ne dispense pas d'être implémenté de manière performante.
Donc en résumé, ce que tu dis peut s'appliqué pour ceux qui écrivent des lib en C, s'ils savent ce qu'il font. Pour les autres je conseille de s'appliquer sur le fonctionnel et la validité de leur code: avoir rapidement un résultat faux (ou un plantage), ça sert à rien.
Pour les Vector et Hashtable, il ne sont pas deprecated à ma connaissance, ms devraient surement l'être, voir même suprimés. Je justement attirer l'attention sur le fait que beaucoup de dev java ne connaissent que ces structure de données qui sont synchronisées par défaut, ce qui bouffe de perf, alors que bien souvent on en a pas besoin. Il faudrait les supprimer (ou déprécier si on veut garder la compatibilité) car il existe d'autres moyens pour synchoniser une collection, et ça ne simplifie pas l'api.