CLASSE XML ULTRA LITE

Commentaire de bAzilew le 07/01/2007 15:46:58

Effectivement, le code produit n'est pas complètement portable, d'autant que j'ai utilisé des trucs propre à Windows me semble t il. Mais je ne pense pas que la différence de vitesse entre les deux libs ne puisse  venir que  de l'algo en lui même, mais plutôt du très grand nombre d'allocation mémoire effectuée dans un gros fichier. Je vais réfléchir à une approche différente comme ne décoder le fichier qu'en stockant les clef + attribut + valeurs dans la même "variable" et ne faire le décodage final qu'au moment de la recherche ou de l'extraction d'une valeur. Mais ds ce cas, c'est la recherche d'une clef qui va prendre du temps. Dans l'exemple présent, la recherche est extrêmement rapide. Il est aussi possible de rendre le code portable,  et ne faire qu'une interface avec la stl, au moment de retourner la valeur. Je ne vois pas trop l'interet d'utiliser la stl pour tout l'algo.  
Je me demande à quel niveau de performance les autres libs xml se positionnent si qqn a déjà fait un essai sur un fichier contenant + de 2,5M de clef, j'aimerai bien savoir ;))

Commentaire de shenron666 le 07/01/2007 17:40:40

editer un fichier texte est autrement plus facile que d'éditer un fichier binaire, et quand il s'agit de décrire une GUI, le xml est un parfait descripteur

Commentaire de bAzilew le 07/01/2007 20:17:16

Personellement, je n'utilise que très rarement le xml pour des fichiers de config ... Il est clair que des structures binaires sont 1001 fois plus adaptées, en tous cas, coté programme.
Mais c'est tout de même bien pratique, quand un utilisateur doit metre les main à l'interieur, s'il n'y a pas de gui pour modifier la config.

Même pour le web, ce n'est pas super. Ca permet à l'homme d'y mettre ses main et comprendre, mais àpart ca, ca fait surtout perdre un max de place sur les dd. Utiliser le xml en base de donnée, je trouve ca absurde. Et pourtant, je suis tombé ces derniers temps sur un prog (concurent) qui ne se servait que de ca, pour stocker ses bases clients etc ... les fichiers atteignaient les 100Mo.

Quelque part, ca me fait plaisir que d'autres n'en pensent pas moin, je me suis toujours dit que le xml devait être util, pour les "autres"..

Commentaire de BruNews le 07/01/2007 20:31:20 administrateur CS

C'est clair et je ne me gratte pas pour le dire.

Commentaire de bAzilew le 08/01/2007 01:09:52

J'en ai besoin, y compris au bureau, parce que bcp de gens aiment suivre les modes, et qu'ils faut le reconnaitre, elle ont aussi leurs avantage.
Par exemple l'irc, ca fait 15 ans qu'on l'utilise, et pourtant, il y a des façons plus efficaces de communiquer entre un programme et un serveur qu'en utilisant un language trop humain pour être rapide. mais on l'utilise toujours ...
Si chaque logiciel, utilise sa petite soupe plutot qu'utiliser un "standard", on a 15000 formats, et au moment ou on veut connecter les choses entre elles, on s'appercoit qu'on aurait peut être gagné du temps à en faire perdre à son cpu au début. pour revenir au xml, l'editer c'est facile, on utilise le wordpad, par exemple, et même un profane peut le modifier sans soucis. Si il y avait un standard binaire (il y en a surement des tonnes ..) accompagné de son editeur, disont un xmlpad .. il devient aussi facil pour n'importe qui de modifier son petit fichier de config, et le format reste adapté. Le probleme ce n'est pas les 100Mo d'ascii sur des disque dur contement croissant, c'est que 1000x 100Mo plus le temps consacré à l'analyser ca devient critique.
Qd les systemes deviennent complexe, le manque d'optimisation de toutes les petites briques qui les composes en font des machines à gaz lourdes et peut efficientes. Il faut considerer tout ca de façon plus globale.  
C'est pas pour rien si un jour les dizaines de .ini de c:\windows se sont transformé en base de registre ... editeur simple, tout le monde  gagne et ce n'est qu'un exemple.

Commentaire de bAzilew le 08/01/2007 10:32:35

oOOops, je me suis trompé de zip. C'est revenu dans l'ordre :)

Commentaire de Arnotic le 09/01/2007 00:56:14 administrateur CS

Donc si tu es obligé de compressé pour gagner de la place ; à la lecture il faut que tu décompresses --> conclusion la décompression te bouffe du temps et du CPU pour rien. Idem lorsque tu dois fermer le fichier ou il faut que tu le compresse.
C'est bien ce qu'on dit c'est un amuse CPU.

Commentaire de bAzilew le 09/01/2007 11:53:56

http://www.w3.org/TR/xbc-properties/
Fichtre, une librairie pour le xbc se code déjà moin à l'aveugle.. c'est autrement plus complexe que le xml :)

Commentaire de shenron666 le 09/01/2007 22:45:56

Arnotic > "la décompression te bouffe du temps et du CPU pour rien"
bah non, pas pour rien ^^
et puis ton CPU, il est là pour faire quelque chose XD
tes arguments sont tout aussi applicables à une image au format PNG / JPEG ou autre
pourquoi ne pas utiliser du RAW brut ? ;-)

de toute façon, le choix entre pratique (xml) et rapide (binaire) a toujours été et restera un choix (discutable ou non) à faire dans une application

et même si le format xml c'est du texte à la base, rien n'empêche de créer un dictionnaire de clefs binaires au chargement (une sorte de compilation) comme le font les langages de script (LUA par exemple est utilisé par World of Warcraft pour les interfaces)

à force d'économiser votre "temps cpu" il va finir par s'ennuyer ^^ (joke)

Commentaire de FredArmoni le 29/04/2009 12:28:16 administrateur CS

Bonjour,
a priori il y a un petit effet indésirable sur les balises xml autofermantes du type    
<Part id="R0001" Manufacturer="MG" Code="24231" Name="Multi9 C60N 4P 32A C" />