I was doing some profiling of load times on COLLADA files, and I figured out the major culprit:
and <v> elements. These elements represent the vast majority of elements in a typical COLLADA file. For example, for one static mesh test file, there were 2507 total elements in the file, 2330 of which are
elements (92% of the total elements). Elements are very slow to initialize and allocate in the XML parser library – each element represents 4 dynamic memory allocations, and a memory overhead of at least 120 bytes each. As a test, I changed all the "
" and “</p>” elements to “.p.” and “./p.” in a file and the XML parsing speed tripled (the XML parsing time represents 90% of my all-inclusive read time).
The performance difference is huge enough that I think it’s worth it to change the spec to include a concept of an “integer array with separators” that’s a single element (similar to how <array> efficiently holds scalar data). Something like this (using a single character as a separator for space efficiency):
<polyarray indexCount="14"> 0 1 2 p 1 2 3 4 p 5 6 7 H 8 9 10 h 11 p </polyarray>
I like the inclusion of the “indexCount” (the total number of indices for the entire array) because it allows me to allocate a buffer for indices without parsing the list first like I have to do now. Note that the capital and lower case “H” elements indicate the start and end of holes – single characters for parsing efficiency.
PLEASE add this or something similar to Collada v1.3!!! I’m tempted to hack it in myself to my own exporter and parser, but I’d rather have an officially supported solution.
Heavy Iron Studios