Yep, c'est ce qui se disais aussi ici, le temps d'exec on s'en fout, sauf qu'on a passé la limite critique de temps de calculs, notamment pour la coordination européenne, les gens ont tellement codé comme des porcs, qu'en à peine 1 journée de boulot, on est passé de 1h de traitement à 30 minutes, un calcul mal placé. Mais régulièrement on fait 2 ou 3 recherche dans les map, là où une seule suffit.
Les gens oublient que le insert en c++ n'insert rien si l'objet est déjà présent (et renvoi une paire (itérateur de l'élément dans la map (nouveau ou ancien), booleen d'insertion), et font des recherche/ajout,
Alors ce genre de petits détails peut ne pas impacter l'appli, quand tu les fais en plein milieu des calculs ça commence à impacter sérieusement les perfs. De même utiliser un vector pour une liste d'éléments dans laquelle on supprime et ajoute des éléments n'est pas non plus optimal.
Je ne parle même pas des allocations dynamique là où une variable locale suffit.
C'est clair qu'une mise-à-jour du matériel est moins chère.
Yep c'est ce que le client pensait aussi, sauf qu'en codant avec des complexité en O(K * N2), le K a 3 ou 4 il commence à faire mal lors des calculs intensifs; si à cela tu ajoute que souvent on est en n3 au et que pas mal de n2 pourraient être en n * log(n), le coût du matériel commence à se faire vraiment sentir, et qui dit serveur de plus (on fait du calcul distribué), dit aussi maintenance en plus.
Y'a quelques années j'avais aussi gagné un facteur 3 sur un ensemble de calculs (une bonne semaine de boulot, factorisation des calculs identique)
Bref optimiser à fond, traquer le point qui fait perdre 3ms, aucun intérêt; par contre timer le code voir où on perd le plus de temps, voir si c'est normal, et dans le cas contraire s'en occuper est indispensable.
Plus récemment, j'ai trouvé dans le code une recherche d'élément dans une map qui ne cherche pas par la clé (problème de jouer avec plusieurs identifiants); le tout dans uns boucle, schématiquement c'est
Le stict minimum, c'est d'avoir une durée qui n'explose pas dès qu'on augment un peu la volumétrie; sinon c'est tous les 2 mois qu'il faut racheter des serveurs, multiplie ça par le nombre de lieu où c'est déployé (5-6 en France, et d'autre à l'étranger), l'achat de serveur n'est pas toujours la bonne solution.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Go ou Rust?
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 5. Dernière modification le 04 juin 2019 à 12:02.
Yep, c'est ce qui se disais aussi ici, le temps d'exec on s'en fout, sauf qu'on a passé la limite critique de temps de calculs, notamment pour la coordination européenne, les gens ont tellement codé comme des porcs, qu'en à peine 1 journée de boulot, on est passé de 1h de traitement à 30 minutes, un calcul mal placé. Mais régulièrement on fait 2 ou 3 recherche dans les map, là où une seule suffit.
Les gens oublient que le insert en c++ n'insert rien si l'objet est déjà présent (et renvoi une paire (itérateur de l'élément dans la map (nouveau ou ancien), booleen d'insertion), et font des recherche/ajout,
Alors ce genre de petits détails peut ne pas impacter l'appli, quand tu les fais en plein milieu des calculs ça commence à impacter sérieusement les perfs. De même utiliser un vector pour une liste d'éléments dans laquelle on supprime et ajoute des éléments n'est pas non plus optimal.
Je ne parle même pas des allocations dynamique là où une variable locale suffit.
Yep c'est ce que le client pensait aussi, sauf qu'en codant avec des complexité en O(K * N2), le K a 3 ou 4 il commence à faire mal lors des calculs intensifs; si à cela tu ajoute que souvent on est en n3 au et que pas mal de n2 pourraient être en n * log(n), le coût du matériel commence à se faire vraiment sentir, et qui dit serveur de plus (on fait du calcul distribué), dit aussi maintenance en plus.
Y'a quelques années j'avais aussi gagné un facteur 3 sur un ensemble de calculs (une bonne semaine de boulot, factorisation des calculs identique)
Bref optimiser à fond, traquer le point qui fait perdre 3ms, aucun intérêt; par contre timer le code voir où on perd le plus de temps, voir si c'est normal, et dans le cas contraire s'en occuper est indispensable.
Plus récemment, j'ai trouvé dans le code une recherche d'élément dans une map qui ne cherche pas par la clé (problème de jouer avec plusieurs identifiants); le tout dans uns boucle, schématiquement c'est
Le stict minimum, c'est d'avoir une durée qui n'explose pas dès qu'on augment un peu la volumétrie; sinon c'est tous les 2 mois qu'il faut racheter des serveurs, multiplie ça par le nombre de lieu où c'est déployé (5-6 en France, et d'autre à l'étranger), l'achat de serveur n'est pas toujours la bonne solution.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent