Oui, mais c'est aussi parce qu'une fonction qui manque, ça se voit
Un logiciel lent, ou qui utilise "trop" de ressources, ç'est plus difficile à voir, car le matos cache ça.
Si c'est extrêmement visible, tu va le corriger. Sinon, c'est invisible.
Par exemple, ce commit existe car c'était visible que le soft était lent.
Un autre exemple, c'est mon propre code ici et ici. J'en parle parce que je me souviens clairement de comment j'ai constaté le souci.
J'ai codé naïvement (i.e., sans cache), ça marchait suffisamment bien, j'ai rajouté des fonctions, j'ai fini mon soft. Puis j'ai commencé à l'utiliser sur un dépôt plus conséquent (mon dépôt perso, pas celui du boulot), et j'ai vu que c'était vraiment long (3 minutes). J'ai vite diagnostiqué le souci, et en rajoutant 2 caches, je suis passé à 0.3 secondes.
Mais je l'avais pas fait avant parce que pendant mes essais et l'usage en production, c'était pas spécialement visible.
Mon but premier, c'était pas faire de un truc rapide (sinon, j'aurais pas fait du python et de l'ansible), mais de faire un truc qui marche pour un poc. Si ça prends 4 secondes au lieu de 2, je vais m'en foutre un peu, parce que le playbook ansible va déjà prendre plus de temps.
Et comme l'article parle surtout des applications clientes, il faut bien voir que le souci, c'est pas "avoir le choix entre une appli mal optimisé" ou "avoir une appli optimisé" mais souvent "avoir 1 appli non optimisé" et "devoir avoir 3 applis optimisés".
C'est pas juste "on ne donne pas de temps pour optimiser", c'est plus "on veut réduire la charge de travail par 3" (ou 2).
[^] # Re: Et le libre ?
Posté par Misc (site web personnel) . En réponse au lien Is software getting worse?. Évalué à 4.
Oui, mais c'est aussi parce qu'une fonction qui manque, ça se voit
Un logiciel lent, ou qui utilise "trop" de ressources, ç'est plus difficile à voir, car le matos cache ça.
Si c'est extrêmement visible, tu va le corriger. Sinon, c'est invisible.
Par exemple, ce commit existe car c'était visible que le soft était lent.
Un autre exemple, c'est mon propre code ici et ici. J'en parle parce que je me souviens clairement de comment j'ai constaté le souci.
J'ai codé naïvement (i.e., sans cache), ça marchait suffisamment bien, j'ai rajouté des fonctions, j'ai fini mon soft. Puis j'ai commencé à l'utiliser sur un dépôt plus conséquent (mon dépôt perso, pas celui du boulot), et j'ai vu que c'était vraiment long (3 minutes). J'ai vite diagnostiqué le souci, et en rajoutant 2 caches, je suis passé à 0.3 secondes.
Mais je l'avais pas fait avant parce que pendant mes essais et l'usage en production, c'était pas spécialement visible.
Mon but premier, c'était pas faire de un truc rapide (sinon, j'aurais pas fait du python et de l'ansible), mais de faire un truc qui marche pour un poc. Si ça prends 4 secondes au lieu de 2, je vais m'en foutre un peu, parce que le playbook ansible va déjà prendre plus de temps.
Et comme l'article parle surtout des applications clientes, il faut bien voir que le souci, c'est pas "avoir le choix entre une appli mal optimisé" ou "avoir une appli optimisé" mais souvent "avoir 1 appli non optimisé" et "devoir avoir 3 applis optimisés".
C'est pas juste "on ne donne pas de temps pour optimiser", c'est plus "on veut réduire la charge de travail par 3" (ou 2).
C'est à mon sens significatif.