Daniel Carrera wrote:
Randomthots wrote:
I repeat, I am *not* making any ****ing assertion! I asked a question;
a not unreasonable question. If the size of the file is 11 times
bigger doesn't it make some sense that that would take longer to wade
through?
You see, you just made an assertion :-) As for your question, it only
makes sense if you don't have a technical background.
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? That's
ludicrous. It's like saying you can drive 20 miles in the same time as
driving 10 miles at the same speed.
Just like someone
who has never programmed before might thing that using short variable
names might be a good optimization. It really is very silly.
What's silly is thinking that the two situations are at all analogous.
Once you've compiled the program, the variable names in the source code
are simply memory pointers. You never deal with them again until you
recompile the source. It's like thinking that omitting comments in the
source will make the program run faster. Thanks for assuming that I'm a
real idiot.
And once you've loaded the file into the spreadsheet, the source of the
file, whether ods, csv, xls or whatever, is irrelevant to how long it
takes to sum a column. That's because the contents of the cells are held
in the same data structure no matter where the data originally came
from. So a cell has all the same attributes regardless of it's original
source. It has a width and height and font and all the rest of these
attributes. The only difference is that reading in a csv will result in
these values being set to the default styles, whereas an ods potentially
could have this cell being different from the next and different from
the next.
Now considering that whichever file is loaded, you end up with the
same data structures in working memory,
Bzzzzz wrong. An OpenDocument spreadsheet has more and more complex data
structures than a CSV file. This is where you show ignorance and lose
the argument.
It POTENTIALLY has more and more complex data. But in this case it
didn't. 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?
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? (Assuming you haven't added stuff like formulas,
formatting, and charts, which I hadn't.)
And it's not unreasonable to speculate that having a 45 MB file loaded
into memory, when you don't have a lot of headroom to start with --
that's why I bought more RAM recently -- could knock you over the edge
into vm swap. It's a speculation, not an assertion.
But when someone with more technical background than you tells you that
this is unlikely to be a significant factor you resist their input with
all your might.
So you're telling me that virtual memory isn't slower than RAM? Wow,
then why did I buy another 512 Meg stick? Any why do some memory
intensive things like image processing run faster now?
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.
After I loaded the OS and OOo, I may very well not had 45 M left over.
Maybe I had 20 or 30. Maybe I had enough room to create the sheet and
cell objects in working memory, but not enough for the intermediate XML
data structure.
This thread would have been a lot shorter if Daniel had said, "That
might be an issue in marginal cases where you run short of RAM,
In other words, you'll only be satisfied if I tell you that you're right
even though I'm confident you are not. 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.
You use pointers to form a data
structure that represents the information in the file. Constructing this
data structure may be a complex operation (this is called "parsing XML")
depending on the complexity of the document, but it is not dependent on
the size of the XML tag.
But the ods version of the same document is no more complex than the
csv. Just a simple table: no formulas; no row, column or cell
formatting; no charts; nothing, just data. It has the structure to
contain all that complexity, but it is unused.
Note that I haven't gotten enough information to actually make that
statement and it may be completely wrong;
But you'd still like me to say it...
I would appreciate it if you could tell me if there is an intermediate
step similar to what I was forced to guess about.
Another question: Is the XML processed in a serial fashion? Is it
necessary to hold the entire file in memory to parse it? If not, then a
real optimization might be an option to save as a flat, uncompressed file.
I give up; I guess I'll never find out.
You might try reading a book on XML and another on compexity theory.
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; I can understand things and I would be perfectly
satisfied with a general outline of the processes involved. If you could
have brought yourself to write a maybe a short paragraph explaining the
rough outlines of the process of loading an XML spreadsheet, this
conversation would have been done a long time ago. Instead you would
rather go on and on and on, post after post, telling me how silly and
stupid I am.
I'm not sure I like you very much anymore.
--
Rod
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
