Randomthots wrote:
So if I have two files... same format... but one is twice as big as the
other... the bigger file isn't going to take longer to load?
Irrelevant example. The fact that a bigger file loads slower doesn't
mean that the fault is on the size of the tag. There are several things
that increase with the size of the file. For example, the number of
elements, the complexity of the tree, the amount of content, etc. All of
those can cause a slowdown and they are unrelated to the size of the tag.
What's silly is thinking that the two situations are at all analogous.
The size of an XML tag *is* analogous to the size of a variable name.
They really, turly are analogous.
Once you've compiled the program,
I was not assuming a compiled language. Assume we're talking about
Python or Ruby. The size of the variable name is inconsequential to the
performance of the program.
Note however, that if I /had/ been talking about a compiled language the
comparison would still be apt. More on this below.
Thanks for assuming that I'm a real idiot.
I'm making no assumption about your intelligence. I'm forming an
educated opinion about your knowledge based on what you say.
It POTENTIALLY has more and more complex data.
Please understand the difference between data and data structures. If
you open a CSV file and immediately save it as OpenDocument you are
saving it into a more complex data structure. Just like an n-ary tree is
a more complex data structure than a two dimmensional array, regardless
of what data you store in them.
Where you lose the argument is that an xls file, like an ods,
also has more and more complex data, but a csv import into Excel is
still slower than loading the equivalent xls. So why is that?
This point is irrelevant to the case you're trying to argue. But I'll
try to answer anyways. I'm not an Excel developer, but I understand that
.doc and .xls files are just a memmory dump. This means that "reading" a
.xls file involves nothing more than sticking it into RAM, with no other
conversion necessary.
And are you telling me that the cell, sheet, chart, etc. objects in
working memory... the stuff you are actually manipulating when you work
with the spreadsheet... aren't the same regardless of the format of the
original data file?
I fail to see what this has to do with your argument.
Statistically, it would be unlikely if the we were talking about a
difference a couple MB. But 45 MB is a substantial fraction of 256.
But here's where you're making silly claims. The fact that unzipping the
file produces a 45MB XML set of files doesn't mean that when it's loaded
into memmory it will actually take up 45MB. It won't. When you load an
XML file into memmory, XML tags are replaced by a pointer structure.
This goes back to the example of compiled software. It's just like, when
you compile software, variable names are replaced by pointers and the
size of the binary is not affected by the size of the variables. In a
similar way, when you read an XML file, the tags are replaced by
pointers, and the size of the XML tag does not affect the size of the
binary data stored in RAM.
Look, when you parse an
XML tree and put it into RAM, you don't put the XML tags in plain text
and re-copy them every time the tag appears.
I wouldn't assume the developers would be that stupid or profligate with
resources.
But that's what you are assuming by saying that the size of the XML tags
matters. It *is* like saying that using longer variables will make a
program run slower.
But the ods version of the same document is no more complex than the
csv.
Please read up on data structures. Find out what an n-ary tree is and
what an array is. Then you'll see that even if you store the same data
in the two structures the fact remains that the n-ary tree is a more
complex data structure and is still slower to navigate. Especially when
all the nodes of the n-ary tree, by design, always add extra data that
isn't present in the array.
Another question: Is the XML processed in a serial fashion? Is it
necessary to hold the entire file in memory to parse it?
In theory it's not necessary, but in practice most content is in the
same place (content.xml) which puts a bit of a limit on how you can
optimize the parsing. For example, if all you wanted was to extract the
author of the document, I could write a program that could get that
information lighting fast, regardless of the size of your document. But
most of the time that's not what you want, you want to actually load the
document contents into the application.
If I had the time I would. Unfortunately, I have to study for
certification exams and wade through some mostly useless labs for
Advanced Switching and Network Security classes. You see I'm not
technically illiterate;
What year are you in?
telling me how silly and stupid I am.
I never said you're stupid. I said you said some very silly things.
I'm not sure I like you very much anymore.
My goal in life is not that you like me or dislike me.
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]
