INI vs JSON vs XML

Dans la plupart des applications, on a besoin d’enregistrer des informations. Au minimum, il faut un fichier de configuration, pour savoir comment se connecter à la base de données qui stockera le reste des infos. Dans le cas d’applications sans base de données, tout sera enregistré dans des fichiers.

À une époque, on écrivait des fichiers binaires, qui correspondaient à de simples «dump» de structures (ceux qui ont fait du C me comprendront). C’était très performant, tant en lecture qu’en écriture, mais posait de nombreux soucis concernant la gestion des chaînes de caractères et l’utilisation des fichiers sur des architectures différentes (avec les problèmes de boutisme qui en résultent).

À la fin des années 90, le XML a fait son apparition et s’est vite répandu. Cela semblait être une solution couvrant la plupart des besoins d’un manière élégante et générale. Un même parseur pouvant lire n’importe quel fichier XML, on pouvait abandonner les parseurs spécifiques à chaque application. La consommation supplémentaire en temps de traitement et en espace disque ont été en partie gommés par l’augmentation de puissance des machines et par la compression des fichiers XML (comme OpenOffice, par exemple, dont les documents sont des fichiers ZIP contenant des fichiers XML).

Avec le temps − et après la période d’engouement maladif pour le XML − on s’est toutefois rendu compte des imperfections du XML, Et que s’il reste très pertinents dans certains cas, principalement lorsqu’il faut pouvoir valider les documents en fonction d’une DTD ou d’un schéma, il ne s’agissait peut-être pas d’un format miraculeux à utiliser systématiquement. Entre autre, le fantasme du parseur universel s’est éteint quand on s’est rendu compte que la logique avait été en grande partie déportée vers l’application qui fait appel au parseur.

Ainsi, un certain nombre d’alternatives sont apparues, toutes n’ont pas survécu. Si le format YAML a ses partisans, le format JSON a réussi à rassembler un nombre massif d’utilisateurs grâce à sa syntaxe assez simple, relativement bien lisible par un être humain, et qui ne bouleversait pas complètement les habitudes (format natif en Javascript, syntaxe très similaire à l’écriture de listes et de tableaux associatifs en Perl). Pourtant, il existe un autre format, plus simple, plus limité fonctionnellement, très bien connu, qui mérite qu’on s’y attarde, c’est le format INI.

Il y a une sorte de snobisme amusant chez les informaticiens quand on parle de ce format. Comme si ses limitations (principalement, le fait de ne pas pouvoir créer plus de 2 niveaux d’imbrication) en faisaient de facto un mauvais choix quelque soit la situation. Mais un format plus simple voulant sûrement dire qu’il est plus facile à lire et interpréter, donc plus rapide à utiliser pour un programme informatique, je m’étais posé quelques questions il y a des ça plusieurs années.
Pour en avoir le cœur net, j’ai voulu vérifier le temps de lecture (je pars du principe qu’un fichier est lu bien plus souvent qu’il n’est écrit) en PHP d’un fichier INI, un fichier JSON et un fichier XML équivalents.

Le contenu du fichier INI :
trululu=pouet
toto=titi

Le fichier JSON :
{
    "trululu": "pouet",
    "toto": "titi"
}

Le fichier XML :
<?xml version="1.0"?>
<data>
    <trululu>pouet</trululu>
    <toto>titi</toto>
</data>

J’ai utilisé les fonctions natives de PHP les plus simples pour lire ces fichiers : parse_ini_file(), json_decode() et simplexml_load_file(). J’ai bouclé sur cinquante mille itérations pour chacun, et j’ai chronométré le temps de traitement.

Le résultat est très intéressant :

  • 1,731576 seconde pour le fichier INI
  • 2,077062 secondes pour le fichier JSON
  • 3,821663 secondes pour le fichier XML

On peut voir qu’il y a un rapport du simple au double entre le fichier INI et le fichier XML. Par contre, la différence est plutôt minime entre le fichier INI et le fichier JSON. Il faut bien garder en tête que la différence augmente avec la complexité du fichier à lire (de même que la taille du fichier).

Ce test n’est évidemment pas représentatif de l’utilisation classique d’un fichier de stockage de données. Mais il donne quand même un éclairage intéressant. Cela a guidé mon choix de l’utilisation de fichiers INI pour la configuration et le stockage des méta-données dans mon système de fichiers réseau FineFS. Le système pouvant se révélé gourmand en entrées-sorties, il fallait privilégier la méthode la plus efficace. Par contre, le framework que j’ai développé dans mon entreprise avait au début des fichiers de configuration au format INI ; mais des besoins de plus grande souplesse se sont fait sentir avec le temps, et nous sommes passés à un format JSON. Par contre il n’y aurait aucune bonne raison pour migrer vers du XML.

7 réponses sur “INI vs JSON vs XML”

  1. Dans ma boite j’ai prototypé le remplacement de SOAP par JSON.

    J’ai diminué la taille du trafic réseau de moitié, et divisé par 60 l’encodage des données coté client.
    Bon il est notoire que SOAP::Lite en perl n’est pas performant, alors que JSON::XS est lui très performant, mais bon, 60x ?

    Le problème du XML et donc de SOAP c’est que tu peux avoir des implémentations véreuses: j’ai retapé un client SOAP, en diminuant la taille de tout les namespaces et en les mettant en header plutot que dans le corps du document comme le faisait le dev précédent. Résultat: taille du message divisée par 5 et perfomance *3, pour le même exact message.

    Bref, oui, JSON semble simpliste, mais dans la plupart des cas, en fait tu n’as pas besoin de l’overhead de SOAP et du XML. Pire, dans notre monde d’applications géantes, ou la performance reste le critère fondamental, on a tout intéret a revenir à des solutions les plus basiques possibles, et les plus rapide possibles.

  2. Merci pour ce témoignage. C’est vrai que le XML est particulièrement verbeux, en plus d’être lent à interpréter comme je le montre dans mon article.

    Pour le stockage «longue durée» de contenus complexes, le XML reste un bon choix (cf. OpenOffice). Mais pour tout ce qui est flux de données, le JSON est difficile à battre. D’ailleurs, de plus en plus de services Web ferment leurs API XML pour ne garder que leurs API JSON.

  3. Superbe site que je viens de découvrir !!

    Concernant les fichiers ini dans les applis web il est impératif de les placer dans un dossier protégé par un htaccess pour éviter toute lecture directe via une url. Souvent ces fichiers contiennent des infos ‘dangereuses’ (code d’accès SGBD par exemple)

  4. @Auguste : Oui, c’est l’évidence même du développement web. Cela reste valable quel que soit le format du fichier, et donc c’est une considération qui s’éloigne un peu du sujet de l’article 😉

  5. J’ai « quand même » trouvé un avantage au XML, le stockage des préférences du site et des modules.
    L’avantage c’est d’avoir quelque chose comme cela

    <?xml version="1.0" encoding="UTF8"?>
    <parametres>
       <rssItems type="integer" descr="Nombre maximum d'éléments à retourner par module, pour le flux RSS">10</rssItems>
    </parametres>

    Une classe Php toute bête permet l’affichage d’un formulaire en lisant le fichier xml (avec une présentation adaptée en fonction du type) dans le back office.
    Par la suite la lecture se fait simplement via l’instruction Php adéquate.

    Pendant un temps j’avais pensé « traduire » le xml vers un fichier .ini durant la sauvegarde car je me posais les même questions relatives à la vitesse.

  6. J’utiliserais le XML pour les structures contenant beaucoup de texte, où les balises sont intéressantes (comme une page web).
    Sinon, que j’aie besoin de performance ou pas, le JSON s’impose.

    @Hervé: pourquoi pas:

    {
       rssItems: {
          type: "integer",
          descr: "Nombre maximum d'éléments à retourner par module, pour le flux RSS",
          value: 10
       }
    }

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.