Optimisation format JSON (modele three.js)

[Aleskweb]

Bonjour,

Je ne savais pas trop ou poster ce sujet mais vu qu'il parle d'optimisation et minimisation de code je l'ai placé ici (J'aurais peut etre du le placer dans algorithme et solutions).

Je m'entraine en ce moment avec three.js, et je charge donc plusieurs modèles 3D (avec animations).
J'aimerais pouvoir minimiser le code de ces modèles JSON pour mettre moins de temps a les charger.

La casi totalité du code est formé par des lignes comme celle ci :

Code :

{ "name": "animation_000021", "vertices": [-0.458561,0.932592,0.291326,-0.338512,0.925817,0.245311,-0.482617,1.1568,0.477249,-0.41756, ................

Or je n'ai pas besoin d'une telle précision et l'exportateur de blender ne propose pas de gerer cette précision.

Imaginons que je ne garde que 2 chiffre après la virgule, j'aurais un gain de 40-50%.

Existe-il des solutions pour ne garder que x chiffre après la virgule (du genre un logiciel ou une option dans un editeur de code) ? Sinon je ferais un script en php mais vu que ces modeles pesent plus de 1Mo (environ 11 000 chiffres a arrondir), je ne suis meme pas sur que le traitement arrive a son terme.


Merci d'avance

[Sephi-Chan]

Tu peux parcourir la structure que tu as exporté et en générer une nouvelle où tu as arrondit ce que tu as avais à arrondir.

[Aleskweb]

C'est ce que j'avais pensé faire avec le script. Mais je voulais m'assurer qu'il n'existait pas une fonction de notepad++ permetant d'arrondir tous les nombres d'un texte. (Du genre avec la fonction remplacer, faire remplacer "0.?*," par "0.?,". Peut etre je devrais voir du coté des expressions régulières)

Sinon un split entre les "." et les "," et je remplace la valeur par les deux premiers chiffres.

[srm]

0.([0-9]{2})([0-9]{1,})?
0.\1
ou 0.$1

[Xenos]

Vérifies que ce gain est bien utile...

Si le fichier de ce modèle 3D est statique, il est probablement préférable d'en faire un XML ou JSON, lourd ou pas, de le sauver comme un fichier "normal" sur le serveur, et de laisser le navigateur du client gérer les histoires de cache: si le fichier est en cache et qu'il n'a pas été modifié (faut pas que les données du modèle 3D changent tout le temps), il ne sera pas (normalement) re-téléchargé. Donc le gain de 40/50% n'est peut-être pas justifié, puisque le téléchargement n'a lieu, en partique, qu'une seule fois (ou que peu de fois, aka, à chaque fois que le navigateur vide son cache).

[Holy]

Vérifies que ce gain est bien utile...

Si le fichier de ce modèle 3D est statique, il est probablement préférable d'en faire un XML ou JSON, lourd ou pas, de le sauver comme un fichier "normal" sur le serveur, et de laisser le navigateur du client gérer les histoires de cache: si le fichier est en cache et qu'il n'a pas été modifié (faut pas que les données du modèle 3D changent tout le temps), il ne sera pas (normalement) re-téléchargé. Donc le gain de 40/50% n'est peut-être pas justifié, puisque le téléchargement n'a lieu, en partique, qu'une seule fois (ou que peu de fois, aka, à chaque fois que le navigateur vide son cache).

Vu le peu de difficulté lié au gain d'octets, je trouve que ça vaut la peine. On parle de rajouter une regex hein, pas de réécrire un parser archi-complexe

[Aleskweb]

Merci pour vos réponses
En fait, une fois qu'on a la fibre, c'est sur ca va super vite, mais quand on habite dans un vieux patelin, les chargements deviennent vite des ennemis :p.

Merci Oxman c'est exactement ce que je cherchais, en fait j'aurais meme pu trouver tout seul vu qu'on a commencé a etudier les expressions régulières en Unix mais la syntaxe n'est pas vraiment la meme je crois.

Je passe de 975ko a 525ko. Ce qui est vraiment pas mal.

[Ter Rowan]

Tu devrais aussi réduire name, vertices, les noms de fichier, quitte a les remettre coté client, ou de modifier ta librairie

[Xenos]

Personnellement, je trouve que c'est du pinaillage. Ok, gagner 400Ko, si tu cible les patelins perdus, pourquoi pas... Après, même avec une connexion à 4Ko/s, entre attendre 100s et 200s, la différence n'est pas énorme, car tu fais attendre l'utilisateur dans les deux cas. Même à 40Ko/s, entre 10s d'attente et 20s, ca change rien. le simple fait d'attendre, même 1 ou 2s, rebutte l'utilisateur (je l'ai constaté en temps réel lors de la sortie de la beta l'eclerd: les utilisateurs ne restent pas si le site ne s'affiche pas immédiatement).

De plus, si tu considère un XML ou tout autre type de fichier "fixe" sur le serveur, le cache du navigateur jouera son rôle: ok, l'utilisateur attendra 20secondes la première fois, mais après, comme c'est le cache qui joue, il n'attendra pas: tu n'as, au final, gagné que 10s sur la première visite.

Ok, au regard de la difficulté (simple regexp), c'est rentable, mais après, de là à jouer l'obfuscation gratuite... j'suis pas pour (mais tu fais comme tu veux ).

[Sephi-Chan]

M'enfin du coup si ça coûte pas un rond à faire, autant peser 2 fois moins, non ? Que font les gens qui font des tas de benchmark tout le temps, si ce n'est pinailler pour gagner des millisecondes (quand ce ne sont pas des microsecondes) ?