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.