Cyrille Moureaux wrote:
Even if, as you say (and as
is true), the tag name doesn't have any bearing on the size of the
document representation in memory (because the actual tag string is only
used in conjunction with the file I/O), each character of the tag has to
be read from the hard drive and inspected while parsing the XML file,
True, the tag has to be read from the hard disk. But then the problem is
hard disk access, not transversing the data in memmory, which is what
our friend was arguing.
which might (keyword, might) have an impact on the time taken to do that
operation (which is if I understand correctly what we're talking about).
The OP thought that the size of the XML tag would be a problem because
it would be slow to transverse in memmory. I tried to explain that
reducing the size of the tag was premature optimization (ie. little gain
in speed for a large increase in obfuscation).
The real question,
however, is whether having one or ten characters in the tag makes any
significant difference in the current parsing process, which quite
frankly I have no idea about and would need to be measured before it's
overly debated, if you want my opinion.
Measuring is always a good idea. I did some measurements (calculated the
size savings from using smaller tags and compared them to the speed of
an IDE drive) and concluded that the probable savings were negligible.
Cheers,
Daniel.
--
/\/`) http://oooauthors.org
/\/_/ http://opendocumentfellowship.org
/\/_/
\/_/ I am not over-weight, I am under-tall.
/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
