Posté par ckyl .
En réponse au journal benchmark pour le fun.
Évalué à 7.
Dernière modification le 20 mars 2014 à 13:55.
Je ne charge pas la map. Il n'y a pas de map, juste une grille de 25 000 cases dans laquelle on se balade et qui ne sert juste qu'à délimiter le monde et poser des villes. Pour le moment il n'y a pas d'images, mais je ne vais pas redire ce que j'ai déjà écrit, suffit juste de lire. J'ai l'impression de voir mes étudiants qui répondent au titre de la question sans avoir lu la question.
Je sais lire et c'est ce qu'on appele une map puisque ca defini ton terrain.
Basiquement une map c'est un fonction (x, y) => t qui te retourne le type de la case. Tu peux l'implémenter comme tu veux. Tu as choisi de la représenter par une matrice textuelle.
Ta grille fait 250K cases, avec une représentation bête et méchante: un octet par case => 250K. Tu peux facilement faire ton estimation au dos d'une envelope à partir de ca. Tu compares ca au reste des coûts de ton chemin d'exécution complet en prod et par rapport à la "résolution" du client. Et tu arrives facilement à estimer si ca vaut le coup de faire autre chose que l'implémentation élégante.
J'ai l'impression de voir mes étudiants qui répondent au titre de la question sans avoir lu la question.
Merci.
Le but n'est pas de gagner ou de perdre, mais de tester, pour le fun
Ce qui est fun c'est de faire des choses qui ont un sens même si ca n'a absolument aucune utilité pratique. Autrement c'est juste faire n'importe quoi.
La ton "benchmark" ne t'apprend rien de nouveau par rapport à un calcul au dos de l'envelope et ne mesure rien de significatif. La conclusion tu pouvais la connaitre avant de la faire:
Tu ne peux pas mesurer de cette facon des opérations estimées sous la ms
Le cout de lire 250K en cache VFS ou sur une DB locale n'est pas significatif par rapport au coup d'exécution de ton script
L'implémentation DB est stupide et ne se compare pas à la version fichier. Dans un cas tu caches ton dans ton espace d'adressage dans l'autre tu vas bourriner la DB à chaque requette. Soit l'implémentation est mauvaise, soit ton test n'a aucun sens
Tu ne peux absolument rien extrapoler de ces mesures. Une regle générale du benchmark est que ca suppose que connaitre ce que tu veux mesurer ainsi que le modèle de performance de ce qu'on mesure AVANT. J'ai appris quoi avec cette mesure ? Comment je peux l'extrapoler pour une grille NxN ou quand j'ai 1000 req/s ? Comment ca se traduit dans mon application ?
Si tu veux être rapide pour le fun commence avec une bonne structure et représentation des données.
[^] # Re: Mouais
Posté par ckyl . En réponse au journal benchmark pour le fun. Évalué à 7. Dernière modification le 20 mars 2014 à 13:55.
Je sais lire et c'est ce qu'on appele une map puisque ca defini ton terrain.
Basiquement une map c'est un fonction (x, y) => t qui te retourne le type de la case. Tu peux l'implémenter comme tu veux. Tu as choisi de la représenter par une matrice textuelle.
Ta grille fait 250K cases, avec une représentation bête et méchante: un octet par case => 250K. Tu peux facilement faire ton estimation au dos d'une envelope à partir de ca. Tu compares ca au reste des coûts de ton chemin d'exécution complet en prod et par rapport à la "résolution" du client. Et tu arrives facilement à estimer si ca vaut le coup de faire autre chose que l'implémentation élégante.
Merci.
Ce qui est fun c'est de faire des choses qui ont un sens même si ca n'a absolument aucune utilité pratique. Autrement c'est juste faire n'importe quoi.
La ton "benchmark" ne t'apprend rien de nouveau par rapport à un calcul au dos de l'envelope et ne mesure rien de significatif. La conclusion tu pouvais la connaitre avant de la faire: