Et là, je ne parle que de la mémoire; discutons un peu du temps d'exécution. En Python (comme dans beaucoup de langages dynamiques), les ensembles pairs/valeurs du JSON sont représentés par des dictionnaires, qui ont un accès O(1) (amorti). Cependant, c'est un accès O(1) à un pointeur sur l'élément voulu. En temps normal, en s'en fiche complètement, une indirection de plus ou de moins, ça ne changera pas grand chose.
Et si c'était maintenant 15 000 indirections? Soudainement le temps d'accès explose...
Je ne comprend pas bien de quoi tu parle... Le boulot d'un parseur json c'est de prendre une chaîne au format json et d'en faire une structure qui permet de se balader dans l'arbre que cette chaîne représentait. Et c'est tout. Et oui, cet arbre devra probablement être entre encodé autrement pour des temps d'accès efficace. Mais c'est pas le problème du parseur.
Ceci étant, la question n'est pas tant de comparer les tailles respectives de la RAM et du fichier incriminé. On peut exploser la RAM tout en étant apparament bien des ordres de grandeur en dessous de sa taille, les zip bombs (ou bombes de décompression ) en étant un bon exemple. Après tout, le fichier original est un ZIP valide, et ne fait que 42 Ko. Quel insensé pourrait oser venir parler de limites physiques? Eh bien celui qui sait que ce fichier, une fois décompressé, fait 4.5 Po (pétaoctets)...
Oui, un autre très bon exemple, c'est pas le problème de la lib qui dézippe, c'est celui de celui qui l'utilise !
c'est vrai que ce genre de concept n'est pas forcément facile à appréhender
Ça ça ressemble beaucoup à de la condescendance que je trouve un chouia déplacée. Mais peut être que je me trompe.
Très prosaïquement, je vois des vois des gens qui sont à la limite de me sortir des arguments de la théorie de l'information pour justifier qu'un parser json ne soit pas capable de parser un fichier json valide qu'un humain pourrait écrire à la main en 15 minutes... C'est techniquement possible facilement, et sans coût, de parser TOUS les fichiers json, avec pour seule limite la mémoire de la machine. Le faire, ne coûte strictement rien (sinon un code un chouia plus compliqué, avec un "push foo" à la place d'un "call bar").
Et qu'est-ce qui ce passe quand le parser json est utilisé dans un contexte un peu compliqué ? Avoir une centaine d'appel de fonction sur la pile c'est pas extra-ordinaire, dans ce cas le parseur va foirer à une profondeur de 30 ? C'est toujours ok, parce qu'il y a forcement une limite ?
En temps normal, en s'en fiche complètement, une indirection de plus ou de moins, ça ne changera pas grand chose.
Et si c'était maintenant 15 000 indirections? Soudainement le temps d'accès explose...
Pourquoi est-ce que l'argument que tu dis à propos des temps d'accès ne vaut pas pour l'utilisation de la pile ?
« En temps normal, un appel de plus ou de moins sur la pile, on s'en fou, imagine maintenant que c'est 1000 ? Soudainement on a un stack overflow. »
[^] # Re: Intérêt ?
Posté par foobarbazz . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à -3. Dernière modification le 26 octobre 2017 à 01:41.
Je ne comprend pas bien de quoi tu parle... Le boulot d'un parseur json c'est de prendre une chaîne au format json et d'en faire une structure qui permet de se balader dans l'arbre que cette chaîne représentait. Et c'est tout. Et oui, cet arbre devra probablement être entre encodé autrement pour des temps d'accès efficace. Mais c'est pas le problème du parseur.
Oui, un autre très bon exemple, c'est pas le problème de la lib qui dézippe, c'est celui de celui qui l'utilise !
Ça ça ressemble beaucoup à de la condescendance que je trouve un chouia déplacée. Mais peut être que je me trompe.
Très prosaïquement, je vois des vois des gens qui sont à la limite de me sortir des arguments de la théorie de l'information pour justifier qu'un parser json ne soit pas capable de parser un fichier json valide qu'un humain pourrait écrire à la main en 15 minutes... C'est techniquement possible facilement, et sans coût, de parser TOUS les fichiers json, avec pour seule limite la mémoire de la machine. Le faire, ne coûte strictement rien (sinon un code un chouia plus compliqué, avec un "push foo" à la place d'un "call bar").
Et qu'est-ce qui ce passe quand le parser json est utilisé dans un contexte un peu compliqué ? Avoir une centaine d'appel de fonction sur la pile c'est pas extra-ordinaire, dans ce cas le parseur va foirer à une profondeur de 30 ? C'est toujours ok, parce qu'il y a forcement une limite ?
Pourquoi est-ce que l'argument que tu dis à propos des temps d'accès ne vaut pas pour l'utilisation de la pile ?
« En temps normal, un appel de plus ou de moins sur la pile, on s'en fou, imagine maintenant que c'est 1000 ? Soudainement on a un stack overflow. »
Pitié... Non, sérieux, c'est ridicule :-)