C'est comme ça qu'on se retrouve avec des OS qui n'ont pas de perfs acceptables avant au moins le SP3, et avec des projets qui rament comme pas possible, pour lesquelq il faut un super calculateur de 40 CPU quad cores juste pour faire un Hello World.
Non, ca c'est parce que le product manager veut un time to market court (eux aussi optimisent leur boulot :p) et "coupe les coins" de partout pour accelerer le dev. Ce qui saute le premier en general, c'est les tests unitaires, puis la QA, puis la doc.
Si t'as pas le temps, t'as pas le temps, prendre les optimisations trop tot va au contraire te faire passer du temps sans aucune garantie de performance au final, ce qui est tres exactement l'inverse de l'effet que tu souhaites dans le cas que tu decris.
Potentiellement, t'auras parie sur le bon cheval, potentiellement pas.
Surtout dans un truc aussi monstrueux qu'un OS ou des tas d'equipes bossent de leur cote et collent leur boulot ensemble a un moment donne.
Ca dépend, il y a des tas d'applis ou on peut savoir par l'expérience ou vont se situer les problèmes de perf.
Ou pas. Ya clairement des cas d'ecoles que tu vas eviter instinctivement parce que tu sais que ca performe tres tres mal, mais c'est pas de l'optimisation ca, c'est juste pas etre completement debile quand t'ecris ton code.
C'est pas comme si c'etait la base des bonnes pratiques, que meme des mecs dont c'est le boulot de regler des problemes de perfs te le diront, ne fait rien tot, ca a plus de chance de te faire perdre du temps au mieux que de faire quoi que ce soit.
Et quand tu fais qq chose, fixe toi un objectif clair a atteindre, sinon tu vas partir dans tous les sens et ne rien faire de valable.
Implemente ton algo d'abord, fait une appli fonctionelle, ensuite il sera temps de le faire tourner plus vite. Si t'en as besoin, parce que c'est meme pas dit que t'en ais besoin au final, ni que le temps passe a optimiser en vaille la chandelle.
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é à 0.
Non, ca c'est parce que le product manager veut un time to market court (eux aussi optimisent leur boulot :p) et "coupe les coins" de partout pour accelerer le dev. Ce qui saute le premier en general, c'est les tests unitaires, puis la QA, puis la doc.
Si t'as pas le temps, t'as pas le temps, prendre les optimisations trop tot va au contraire te faire passer du temps sans aucune garantie de performance au final, ce qui est tres exactement l'inverse de l'effet que tu souhaites dans le cas que tu decris.
Potentiellement, t'auras parie sur le bon cheval, potentiellement pas.
Surtout dans un truc aussi monstrueux qu'un OS ou des tas d'equipes bossent de leur cote et collent leur boulot ensemble a un moment donne.
Ou pas. Ya clairement des cas d'ecoles que tu vas eviter instinctivement parce que tu sais que ca performe tres tres mal, mais c'est pas de l'optimisation ca, c'est juste pas etre completement debile quand t'ecris ton code.
C'est pas comme si c'etait la base des bonnes pratiques, que meme des mecs dont c'est le boulot de regler des problemes de perfs te le diront, ne fait rien tot, ca a plus de chance de te faire perdre du temps au mieux que de faire quoi que ce soit.
Et quand tu fais qq chose, fixe toi un objectif clair a atteindre, sinon tu vas partir dans tous les sens et ne rien faire de valable.
Implemente ton algo d'abord, fait une appli fonctionelle, ensuite il sera temps de le faire tourner plus vite. Si t'en as besoin, parce que c'est meme pas dit que t'en ais besoin au final, ni que le temps passe a optimiser en vaille la chandelle.
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.