Désolé que tu vois cet échange comme insensé; c'est vrai que ce genre de concept n'est pas forcément facile à appréhender, et qu'il peut être utilisé à mauvais escient pour mal faire les choses (un peu comme le out of spec en ingénierie traditionnelle, où on prend pour excuse que rien n'est garantit en dehors des spécifications pour faire vraiment n'importe quoi alors qu'une simple modification améliorerait beaucoup ce cas de figure).
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)...
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...
Est-ce parce qu'on a dépassé les limites de la RAM? Non. Parce qu'on surcharge le processeur de calculs? Pas vraiment. Et pourtant ça ne va pas, tout simplement parce que la supposition de départ ayant mené à la conception des dictionnaires en Python est que les accès sont, en majorité, à plat.
Est-ce qu'on pourrait imaginer une autre structure de données plus adaptée à ce genre de chose? Bien sûr. Est-ce qu'on veut le faire? Certainement pas, et ce n'est ni par paresse, ni par esprit de contradiction. Les choix de design peuvent être discutés, mais peu importe ce que l'on choisit, il y aura des perdants.
[^] # Re: Intérêt ?
Posté par Kalenx . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 10.
Désolé que tu vois cet échange comme insensé; c'est vrai que ce genre de concept n'est pas forcément facile à appréhender, et qu'il peut être utilisé à mauvais escient pour mal faire les choses (un peu comme le out of spec en ingénierie traditionnelle, où on prend pour excuse que rien n'est garantit en dehors des spécifications pour faire vraiment n'importe quoi alors qu'une simple modification améliorerait beaucoup ce cas de figure).
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)...
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...
Est-ce parce qu'on a dépassé les limites de la RAM? Non. Parce qu'on surcharge le processeur de calculs? Pas vraiment. Et pourtant ça ne va pas, tout simplement parce que la supposition de départ ayant mené à la conception des dictionnaires en Python est que les accès sont, en majorité, à plat.
Est-ce qu'on pourrait imaginer une autre structure de données plus adaptée à ce genre de chose? Bien sûr. Est-ce qu'on veut le faire? Certainement pas, et ce n'est ni par paresse, ni par esprit de contradiction. Les choix de design peuvent être discutés, mais peu importe ce que l'on choisit, il y aura des perdants.