I was evaluating TinyXML for use with a PDA application. The size of the parser code certainly is appealing, but the run time foot print is a bit harsh. I have data exported from a database and stored as XML on a compact flash card. Typically that's 256mb or more data in a single file. Which TinyXML will attempt to read into memory all at once and horribly fail.
While it is true that reading a file all at once can be faster it's can heavy price to pay. Is this perceived as a bug/design flaw by anyone else? I can certainly resolve the issue for my personal needs, but is there a greater desire to give TinyXML a smaller "tunable" runtime foot print?
Chuck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's an interesting idea...but would take some thinking. The parser "backs up" and all kinds of odd behavior. It wasn't really built to be a streaming parser, which is what you need to succeed at having a smaller runtime footprint.
Implementing this would be useful, improve the existing streaming code, but would certainly not be trivial.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was evaluating TinyXML for use with a PDA application. The size of the parser code certainly is appealing, but the run time foot print is a bit harsh. I have data exported from a database and stored as XML on a compact flash card. Typically that's 256mb or more data in a single file. Which TinyXML will attempt to read into memory all at once and horribly fail.
The offending functionality comes from
bool TiXmlDocument::LoadFile( const char* filename )
While it is true that reading a file all at once can be faster it's can heavy price to pay. Is this perceived as a bug/design flaw by anyone else? I can certainly resolve the issue for my personal needs, but is there a greater desire to give TinyXML a smaller "tunable" runtime foot print?
Chuck
It's an interesting idea...but would take some thinking. The parser "backs up" and all kinds of odd behavior. It wasn't really built to be a streaming parser, which is what you need to succeed at having a smaller runtime footprint.
Implementing this would be useful, improve the existing streaming code, but would certainly not be trivial.