Si je veux dire "bold", je vais mettre "bold". Point barre.
C'est genial, t'es en train de me dire que le jour ou cette partie de texte devra changer tu devras t'amuser a tout changer plutot que changer un unique #define/const ? T'as des techniques de programmation geniales.
Je parle du coût d'avoir des symbols long au-lieu de symbols cours. Parser un fichier xml, même si les symbols sont longs, le temps passer à lire les symbols et les comparer à une table est ridicule.
The simplest way to see the impact for yourself is to just take an application like OpenOffice, and get a decent sized spreadsheet (I took a file with just one worksheet, that was 15 columns by 15,000 rows). Save it in ODF and make 2 copies. In one of the copies open content.xml and change some of the namespace prefixes to make them much longer. I aimed to make it so that the resulting content.xml file was about 3 times larger than the original since this helps replicate the size difference you would see if we changed SpreadsheetML so that it's tag length was longer and more descriptive like ODF (it would probably be more than that, but I found that making content.xml 3 times larger was more than enough to get a noticable slowdown in load times). I used namespace prefix approach because it's the easiest way to replicate the effect of a larger element name without changing the actual element names (since that would prevent the file from being readable by OpenOffice). In my test, by essentially tripling the size of the element names, I found that the file went from loading in about 9 seconds to taking about 11 seconds.
Voila, je te proposes de faire l'essai toi meme...
[^] # Re: comparaison ODF et OpenXML
Posté par pasBill pasGates . En réponse à la dépêche Le Danemark rend obligatoires les standards ouverts MAIS.... Évalué à 0.
C'est genial, t'es en train de me dire que le jour ou cette partie de texte devra changer tu devras t'amuser a tout changer plutot que changer un unique #define/const ? T'as des techniques de programmation geniales.
Je parle du coût d'avoir des symbols long au-lieu de symbols cours. Parser un fichier xml, même si les symbols sont longs, le temps passer à lire les symbols et les comparer à une table est ridicule.
http://blogs.msdn.com/brian_jones/archive/2006/10/26/perform(...)
The simplest way to see the impact for yourself is to just take an application like OpenOffice, and get a decent sized spreadsheet (I took a file with just one worksheet, that was 15 columns by 15,000 rows). Save it in ODF and make 2 copies. In one of the copies open content.xml and change some of the namespace prefixes to make them much longer. I aimed to make it so that the resulting content.xml file was about 3 times larger than the original since this helps replicate the size difference you would see if we changed SpreadsheetML so that it's tag length was longer and more descriptive like ODF (it would probably be more than that, but I found that making content.xml 3 times larger was more than enough to get a noticable slowdown in load times). I used namespace prefix approach because it's the easiest way to replicate the effect of a larger element name without changing the actual element names (since that would prevent the file from being readable by OpenOffice). In my test, by essentially tripling the size of the element names, I found that the file went from loading in about 9 seconds to taking about 11 seconds.
Voila, je te proposes de faire l'essai toi meme...