Quand tu es dev JS/python, même compétent, je pense que tu as moins de levier pour l'optimisation.
L'optimisation c'est pas que économiser un cycle sur une boucle for, ça c'est le truc de fin quand t'es limite où que ton but c'est la performance.
L'optimisation c'est aussi ne pas
* refetcher des ressources que t'as déjà en local,
* c'est pas reparser 15 fois ton json,
* c'est ne pas effectuer une deep copy à coup de JSON.parse(JSON.stringify(obj))
* c'est ne pas faire history4 = clone(history3); history3=clone(history2); history2=clone(history1); history1=clone(state)
Et je précise que les history étaient des json clonés par la méthode précédente (et c'était pas mon code, ni une génération à moi)
En javascript y'a structuredClone pour faire des deep copy.
en optimisé (ou simplement pas de conneries)
history4=history3; histroy3=history2; history2=history1; history1=structuredClone(state);
Je parle même pas du fait qu'avant cette version moche le state était un json sringifié, que le truc en question allait chercher des éléments dans le state, et comme il le faisait plusieurs fois pour un même passage il le parsait plusieurs fois...
Bref pour résumer, il y'a plusieurs optimisation, et la première, la plus importante, celle qui fait que ton truc à des performance correcte, c'est au plus haut niveau que ça se fait, c'est éviter de faire des calculs inutiles (t'auras beau les optimiser a fond au niveau assembleur, ce sera toujours des calculs qui prennent du temps pour rien); c'est le choix de tes algorithmes et façon de traiter les données, je choix du type de donnée (map, set, tableau...); typiquement si t'as des tableau que t'accède toujours aux éléments à coup de tab.filter( t => t.id === val) la map ou l'objet js peut être plus pertinent.
L'intérêt de (削除) s (削除ここまで)ces langages c'est essentiellement la clarté / simplicité du code pour effectuer une tâche donnée
Je te montrerais bien des codes js pour effectuer une tâche donnée, la simplicité est absente, et la clarté est aux oubliettes.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pendant ce temps
Posté par fearan . En réponse au journal De développeur à orchestrateur, comment l'IA a changé ma vie. Évalué à 10.
L'optimisation c'est pas que économiser un cycle sur une boucle for, ça c'est le truc de fin quand t'es limite où que ton but c'est la performance.
L'optimisation c'est aussi ne pas
* refetcher des ressources que t'as déjà en local,
* c'est pas reparser 15 fois ton json,
* c'est ne pas effectuer une deep copy à coup de JSON.parse(JSON.stringify(obj))
* c'est ne pas faire history4 = clone(history3); history3=clone(history2); history2=clone(history1); history1=clone(state)
Et je précise que les history étaient des json clonés par la méthode précédente (et c'était pas mon code, ni une génération à moi)
En javascript y'a structuredClone pour faire des deep copy.
en optimisé (ou simplement pas de conneries)
history4=history3; histroy3=history2; history2=history1; history1=structuredClone(state);
Je parle même pas du fait qu'avant cette version moche le state était un json sringifié, que le truc en question allait chercher des éléments dans le state, et comme il le faisait plusieurs fois pour un même passage il le parsait plusieurs fois...
Bref pour résumer, il y'a plusieurs optimisation, et la première, la plus importante, celle qui fait que ton truc à des performance correcte, c'est au plus haut niveau que ça se fait, c'est éviter de faire des calculs inutiles (t'auras beau les optimiser a fond au niveau assembleur, ce sera toujours des calculs qui prennent du temps pour rien); c'est le choix de tes algorithmes et façon de traiter les données, je choix du type de donnée (map, set, tableau...); typiquement si t'as des tableau que t'accède toujours aux éléments à coup de tab.filter( t => t.id === val) la map ou l'objet js peut être plus pertinent.
Je te montrerais bien des codes js pour effectuer une tâche donnée, la simplicité est absente, et la clarté est aux oubliettes.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent