Si tu recodes String.split, alors que tu n'utilises cette fonction uniquement pour lire une configuration à l'init, cela ne sert à rien. Par exemple.
Oui ca c'est enfoncer des portes ouverte ;)
D'ailleurs il m'a fallu attendre près de 10 ans pour en avoir besoin.
Sauf pour le gros grain, mais une fois ton archi faite, en général les estimations aux doigts mouillés des "bottlenecks" de performance, sont en général fausses.
Personne n'a dit de faire de la micro-optimisation au doigt mouillé il me semble... Choisir une représentation mémoire, une structure de donnée ou un algorithme en fonction des besoins et non de ce que te files la lib standard (tant mieux si ca correspond) ce n'est pas ca en tout cas.
Il me semble que les discussions se sont croisés.
L'exemple était donné pour répondre à un commentaire qui disait pour caricaturer "y'a tout de dispo en plus rapide que tu ne peux l'écrire dans les libs, réfléchit pas trop et utilise". Ce a quoi je répondais que de mon expérience ce n'est pas vrai. Tu te retrouves fréquemment a réécrire ou implémenter toutes sortes de choses pour des raisons objectives. À aucun moment je n'ai évoqué l'idée de recoder un split au pif.
Le coup de savoir estimer le coût de quelque chose, c'est ce que toi tu appelles "choisir l'archi". Je ne pense pas qu'on soit fondamentalement en désaccord.
"Choisir l'archi" c'est par exemple implémenter un Hyperloglog++ par ce que tu as besoin de faire des dizaines de milliers d'estimations de cardinnalité d'ensemble de millions/milliards d'éléments. C'est ne pas utiliser une collection standard quand tu sais que ca te fait 4x en empreinte mémoire et que ca va te poser problème pour ces objets en particulier. Bref se focaliser sur ce qui est important pour répondre à un besoin donné.
Après on profile et on gratte ce qu'il reste à gratter.
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
Oui ca c'est enfoncer des portes ouverte ;)
D'ailleurs il m'a fallu attendre près de 10 ans pour en avoir besoin.
Personne n'a dit de faire de la micro-optimisation au doigt mouillé il me semble... Choisir une représentation mémoire, une structure de donnée ou un algorithme en fonction des besoins et non de ce que te files la lib standard (tant mieux si ca correspond) ce n'est pas ca en tout cas.
Il me semble que les discussions se sont croisés.
L'exemple était donné pour répondre à un commentaire qui disait pour caricaturer "y'a tout de dispo en plus rapide que tu ne peux l'écrire dans les libs, réfléchit pas trop et utilise". Ce a quoi je répondais que de mon expérience ce n'est pas vrai. Tu te retrouves fréquemment a réécrire ou implémenter toutes sortes de choses pour des raisons objectives. À aucun moment je n'ai évoqué l'idée de recoder un split au pif.
Le coup de savoir estimer le coût de quelque chose, c'est ce que toi tu appelles "choisir l'archi". Je ne pense pas qu'on soit fondamentalement en désaccord.
"Choisir l'archi" c'est par exemple implémenter un Hyperloglog++ par ce que tu as besoin de faire des dizaines de milliers d'estimations de cardinnalité d'ensemble de millions/milliards d'éléments. C'est ne pas utiliser une collection standard quand tu sais que ca te fait 4x en empreinte mémoire et que ca va te poser problème pour ces objets en particulier. Bref se focaliser sur ce qui est important pour répondre à un besoin donné.
Après on profile et on gratte ce qu'il reste à gratter.