D’où vient cette idée ? J’ai déjà eu l’occasion d’exprimer mon désaccord à ce sujet : lorsque la rapidité une contrainte importante l’optimisation doit être pensée dès la conception. À moins de vouloir refaire le travail deux fois.
Regle de base d'optimisation: don't do it.
Deuxieme regle de base: ne touche a rien tant que t'as pas de chiffres et que t'as pas clairement identifie le plus gros goulet d'etranglement ET qu'il est avere que tu peux gagner qq chose de significatif.
Troisieme regle de base: le goulet d'etranglement n'est pas la ou tu le penses.
En gros, l'idee c'est d'architecturer ton appli en ayant une certaine idee d'ou les points chauds vont probablement se trouver, faire une implementation naive, mais pas trop non plus.
Ensuite, et seulement quand ca marche et que c'est fonctionel, tu peux conmencer a regarder ou le temps est passe, fixer un but a atteindre et commencer a travailler pour l'atteindre.
Tu passes ton temps dans ton layer db, c'est quoi le probleme? Requete trop couteuse, tu perds trop de temps a instantier des objets une fois la requete recue, ton pool de connexions est trop petit et tu prends un hit massif au moment de le faire grossir, tu fais trois requete la ou tu pourrais n'en faire qu'une? Les solutions vont etre diametralement opposees.
T'as une interface utilisateur qui est lente? Est ce du a une vue trop complexe, t'abuses du layout automatique et doit implementer ton propre layout, tu fais des fetchs reseaux/disque sur le ui thread, tu passes ton temps a creer/ajouter des widgets sur la scene, tu fais des refresh constamment sur une table de 200 000 elements? La encore, les solutions sont diametralement opposees.
Tes calculs sont trop lents, quel est le probleme? Code trop gros qui rentre pas dans le cache? Mauvaise localite des donnees qui te fait prendre un cache miss a chaque fois? Trop grande precision du calcul?
Mauvais tuning du gc ou tu retiens des objets trop longtemps, qui passent donc dans la generation superieure alors qu'ils ne devraient pas?
Dans chacun des cas donnes, il faut avoir une appli presque finie pour estimer quel est le probleme et y apporter une vraie solution.
Sinon tout ce que tu fais, c'est resoudre un probleme qui n'existe pas, voir potentiellement, tu vas passer du temps a pas le resoudre, si tu paries sur le mauvais cheval.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Compréhension
Posté par pasScott pasForstall . En réponse au journal Programmation : la complexité c'est le mal. Évalué à 4.
Regle de base d'optimisation: don't do it.
Deuxieme regle de base: ne touche a rien tant que t'as pas de chiffres et que t'as pas clairement identifie le plus gros goulet d'etranglement ET qu'il est avere que tu peux gagner qq chose de significatif.
Troisieme regle de base: le goulet d'etranglement n'est pas la ou tu le penses.
En gros, l'idee c'est d'architecturer ton appli en ayant une certaine idee d'ou les points chauds vont probablement se trouver, faire une implementation naive, mais pas trop non plus.
Ensuite, et seulement quand ca marche et que c'est fonctionel, tu peux conmencer a regarder ou le temps est passe, fixer un but a atteindre et commencer a travailler pour l'atteindre.
Tu passes ton temps dans ton layer db, c'est quoi le probleme? Requete trop couteuse, tu perds trop de temps a instantier des objets une fois la requete recue, ton pool de connexions est trop petit et tu prends un hit massif au moment de le faire grossir, tu fais trois requete la ou tu pourrais n'en faire qu'une? Les solutions vont etre diametralement opposees.
T'as une interface utilisateur qui est lente? Est ce du a une vue trop complexe, t'abuses du layout automatique et doit implementer ton propre layout, tu fais des fetchs reseaux/disque sur le ui thread, tu passes ton temps a creer/ajouter des widgets sur la scene, tu fais des refresh constamment sur une table de 200 000 elements? La encore, les solutions sont diametralement opposees.
Tes calculs sont trop lents, quel est le probleme? Code trop gros qui rentre pas dans le cache? Mauvaise localite des donnees qui te fait prendre un cache miss a chaque fois? Trop grande precision du calcul?
Mauvais tuning du gc ou tu retiens des objets trop longtemps, qui passent donc dans la generation superieure alors qu'ils ne devraient pas?
Dans chacun des cas donnes, il faut avoir une appli presque finie pour estimer quel est le probleme et y apporter une vraie solution.
Sinon tout ce que tu fais, c'est resoudre un probleme qui n'existe pas, voir potentiellement, tu vas passer du temps a pas le resoudre, si tu paries sur le mauvais cheval.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.