Henrik Sundberg wrote:
This is under work according to the link:
When importing, whole streams are read into memory at once and are
then read from memory. They should be uncompressed and written to
temporary files and be read from there instead. If the stream size is
less than a nominal
2005/12/13, Mathias Bauer [EMAIL PROTECTED]:
Randomthots wrote:
Mathias Bauer wrote:
So possibly the size of the Calc document created from the file (the
memory consumption of Calc itself) caused the swapping you experienced
but not the xml content itself that (as outlined above)
Randomthots wrote:
Mathias Bauer wrote:
So possibly the size of the Calc document created from the file (the
memory consumption of Calc itself) caused the swapping you experienced
but not the xml content itself that (as outlined above) never is read
into memory as a whole. This is what
Mathias Bauer wrote:
You are not alone, many people wonder and the developers already started
trying to solve this problem. There are a lot of known problems as well
as some ways to fix them but this is something that needs to be
investigated carefully. Expect to see something happen in future
Please move this thread back on topic or move it to another forum.
On topic here means discussion of items *directly* relevant to OpenOffice.org.
Thank you for your cooperation.
--
CPH : OpenOffice.org contributor
-
To
On Fri, 2005-12-09 at 17:02 -0600, Randomthots wrote:
Ian Lynch wrote:
A school here rang me to say they had had a visit by FAST. UK version of
BSA. They were threatened with death if they had any pirate software and
then offered some software for £5000 to check and audit their servers.
On Fri, 2005-12-09 at 21:06 -0600, Randomthots wrote:
Do you know what a EULA is? Do you know what a contract is? Jonathon's
enforcers are lawyers with subpoenas signed by judges.
Not necessarily. The evidence I have is of people trying to gain entry
and use fear to sell products without any
Great info!
What happens at SAVE? Isn't the complete unzipped file needed to do
the ZIP-analysis? Is there a way to ZIP on the fly? Does OOo implement
the ZIP algorithm itself, using the fact that it knows about the tags
it'll use from the beginning?
(I expect that auto save will be very
Ian Lynch wrote:
On Fri, 2005-12-09 at 09:38 +0100, Henrik Sundberg wrote:
This was the statement:
If a vendor failed to adhere to that, then the vendor was shut down,
and all assets went to Microsoft.
And this was the question related to it:
Care to give any evidence at all that this
On Fri, 2005-12-09 at 07:12 -0600, Randomthots wrote:
It's frustrating and often sad and
tragic, but it's not the mafia. And it's not illegal or criminal.
A school here rang me to say they had had a visit by FAST. UK version of
BSA. They were threatened with death if they had any pirate
Randomthots wrote:
Bingo!! By jove he's got it! That's what I've been trying to get across
unsuccessfully. The size of the tags *does* make a difference if it
makes the file so big that it won't fit into RAM anymore. That's what my
disc thrashing comment was meant to convey, but I guess
Giuseppe Bilotta wrote:
Tuesday, December 6, 2005 John W. Kennedy wrote:
There is /one/ issue that comes up here. /Does/ OOo parse the XML on the
fly as it is unpacked, or does it produce the (e.g.) 45MB XML files and
then parse and discard them? Similarly, when saving, are the XML files
Thursday, December 8, 2005 Mathias Bauer wrote:
You are lucky that you didn't place the bet. :-)
OOo doesn't do that. First it processes each XML stream independently
(and other streams only on demand) and second it never loads any whole
uncompressed stream into memory but instead has an
Mathias Bauer wrote:
So possibly the size of the Calc document created from the file (the
memory consumption of Calc itself) caused the swapping you experienced
but not the xml content itself that (as outlined above) never is read
into memory as a whole. This is what Daniel tried to point out:
Hi Daniel,
Daniel Carrera wrote:
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
Joerg Barfurth wrote:
Take a look at Tools-Options-Load/Save-General. There is an option
'optimize XML for size'. This option defaults to 'optimize' and iirc it
was introduced in an early effort to make the file load process faster.
I know about that option. I always turn it off because I
Daniel Carrera wrote:
Joerg Barfurth wrote:
Take a look at Tools-Options-Load/Save-General. There is an option
'optimize XML for size'. This option defaults to 'optimize' and iirc
it was introduced in an early effort to make the file load process
faster.
I'd assume that the effect of this
Joerg Barfurth wrote:
It'd be interesting to find out why they added that option. Whether it
speeds parsing, or to improve the file size on-disk, or if (as you
suggest) is to reduce the size on memmory.
Huh? What do you think I suggest?
I think that you suggest that the reduction in
On Mer 7 décembre 2005 15:09, Daniel Carrera wrote:
Joerg Barfurth wrote:
Take a look at Tools-Options-Load/Save-General. There is an option
'optimize XML for size'. This option defaults to 'optimize' and iirc it
was introduced in an early effort to make the file load process faster.
I know
Tuesday, December 6, 2005 John W. Kennedy wrote:
There is /one/ issue that comes up here. /Does/ OOo parse the XML on the
fly as it is unpacked, or does it produce the (e.g.) 45MB XML files and
then parse and discard them? Similarly, when saving, are the XML files
produced and then compressed
Randomthots wrote:
I was speaking in general terms. Get away from ods and xml for a second
and consider two files, jpegs, for example. The bigger file will take
longer to process simply because it will take more cycles to work your
way through it.
In other words, since you can't accept that
Just for the heck of it, I decided to provide some actual data. Since I
don't have any sufficiently humongous OpenDocument files, I made a dummy.
test1.xml is
parent
child[three random numbers]/child [repeat 1,000,000 times]
/parent
test1.zip contains a copy of test1.xml
test2.xml
John W. Kennedy wrote:
12/05/2005 10:49 PM69,999,781 test1.xml
12/05/2005 10:53 PM26,167,179 test1.zip
12/05/2005 11:05 PM 167,999,781 test2.xml
12/05/2005 11:09 PM28,641,918 test2.zip
Clearly, the size of the tagname is fairly unimportant.
Bingo. The tag
Daniel Carrera wrote:
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
This is only testing the behaviour of ZIP and has, in my opinion, no
bearing to the discussion.
I am surprised by the difference in file size though. I though the ZIP
files should differ by ~49 bytes.
/$
2005/12/6, John W. Kennedy [EMAIL PROTECTED]:
Just for the heck of it, I decided to provide
On 12/6/05, Sven Aerts [EMAIL PROTECTED] wrote:
How's the law suits against MS and the illegal sending of HD info ?
In what countries in Asia governments are forbidding to use MS in
governmental application?
How fast in Linux evolving?
Do you know how to use Google? Give it a try! It's
Daniel Carrera wrote:
John W. Kennedy wrote:
12/05/2005 10:49 PM69,999,781 test1.xml
12/05/2005 10:53 PM26,167,179 test1.zip
12/05/2005 11:05 PM 167,999,781 test2.xml
12/05/2005 11:09 PM28,641,918 test2.zip
Clearly, the size of the tagname is fairly
Daniel Carrera wrote:
In other words, since you can't accept that you were wrong, you are
changing the question.
Merely clarifying it, since you didn't seem to comprehend the point.
Very much like a table structure in html. I was sort of surprised that
there wasn't any indication of
Randomthots wrote:
So if that all is true, then what we probably really have going on here
is that OOo processes the file inefficiently, and in a fashion that
makes heavy demands on memory, and that inefficiency is only exacerbated
by the file size, which *is* a direct mathematical
Randomthots wrote:
So you've proven that xml is inefficient for storing highly structured
data.
XML is not designed to be efficient. XML is an interchange format, and
was designed first and foremost for interchange robustness :
1. it's generic and extensible
2. an xml file can be validated
Roger Markus wrote:
On 12/6/05, Sven Aerts [EMAIL PROTECTED] wrote:
How's the law suits against MS and the illegal sending of HD info ?
In what countries in Asia governments are forbidding to use MS in
governmental application?
How fast in Linux evolving?
Do you know how to use Google?
Nicolas Mailhot wrote:
Randomthots wrote:
Remember, this was a big file. 63,260 rows by 7 columns. That's 442,820
instances of the 80 bytes of taggage surrounding each cell (35 MB,
total) plus the tags at the start of each row (times 63,260) plus all
the header information. Apparently with
That matches a lot of my observations, especially management decisions
involving ignoring non-MS options.
The whole MS phenomenon makes sense only if you look at it from the
perspective of a political or social / ideological movement.
-Lars
Lars Nooden ([EMAIL PROTECTED])
Software
On Mon, 2005-12-05 at 00:04 -0500, mark wrote:
John W. Kennedy wrote:
Windows' easy-to-use interface,
A second-generation copy.
Office's powerful business apps,
Fundamentally designed in the 80's. Word for DOS and Multiplan were
genuinely innovative (though, as I understand it, Word
On Sun, 2005-12-04 at 20:15 -0600, Randomthots wrote:
Of course, the point remains that OOo has plenty of room for
optimization :)
Bingo!! By jove he's got it! That's what I've been trying to get across
unsuccessfully.
I don't think any of us disagree - why would I be advocating
Daniel Carrera wrote:
Randomthots wrote:
Aha!! Information. At last. It's terse, sketchy, and comes with an
attitude, but at least it's a bit of data. Maybe... I notice you used
the word probably. In other words, you don't know either.
But you're likely prone to disagree with me just on
Ian Lynch wrote:
On Mon, 2005-12-05 at 00:04 -0500, mark wrote:
John W. Kennedy wrote:
Windows' easy-to-use interface,
A second-generation copy.
Office's powerful business apps,
Fundamentally designed in the 80's. Word for DOS and Multiplan were
genuinely innovative (though, as I
Ian Lynch wrote:
No, you are persevering on an untenable argument because you lack the
technical knowledge to back it up. The people with the technical
knowledge know you are mistaken but do not necessarily know the exact
reason for your performance problem but they do know its not the thing
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
On Mon, 2005-12-05 at 10:54 -0500, mark wrote:
Ian Lynch wrote:
On Mon, 2005-12-05 at 00:04 -0500, mark wrote:
John W. Kennedy wrote:
Windows' easy-to-use interface,
A second-generation copy.
Office's powerful business apps,
Fundamentally designed in the 80's. Word for DOS and
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
Dear Markus... can you please stimulate Rod in continuing with MS ...
otherwhise we're loosing our competitive advantage.
PS
How's the law suits against MS and the illegal sending of HD info ?
In what countries in Asia governments are forbidding to use MS in
governmental application?
How fast
Nicolas Mailhot wrote:
Randomthots wrote:
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.
Aren't you a bit old to go sulking ?
Daniel is a fine chap and you don't deserve half the explanations
Daniel Carrera wrote:
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.
There is /one/ issue that comes up here. /Does/ OOo parse the XML on the
fly as
Hi Daniel,
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
On 12/3/05, Ian Lynch [EMAIL PROTECTED] wrote:
On Fri, 2005-12-02 at 09:58 -0600, Randomthots wrote:
If I'm not actively concerned about cross-platform and/or
cross-application compatibility, then XML is mostly meaningless to me.
But anyone an use that argument about any feature of MSO
On Sat, 2005-12-03 at 13:52 -0600, Rod Engelsman wrote:
Ian Lynch wrote:
Its the people that use Windows and who are used to Outlook that are
making all the fuss. Most Linux users don't seem to have the problem.
Well... with all due respect and not to put too fine a point on it, most
Roger Markus wrote:
Same here. There's the moral issue as well of not supporting the illegal
organization Microsoft that is damaging to the computer industry as a
whole. Buying their products only strengthens the monster. If they were an
honest company it would be a different story, but
On Sun, 2005-12-04 at 10:06 -0600, Randomthots wrote:
I think one of the things to ask yourself is, Why OOo at all?
Because its a means to an end.
I think that you can't categorize these things as neatly as you would
like.
I'm just saying what I use and why. Categories might or might not
Randomthots wrote:
That's the part where you turn into an ass. If you call me silly, I will
call you an ass...
Calling you silly is mild, calling me an ass is rude. That's okay
though, I don't mind :)
But you didn't explain anything at all.
You didn't explain anything at all, I explained
On Sun, 2005-12-04 at 16:54 +, Daniel Carrera wrote:
I'd like to add that this is a good example of premature optimization
which is the hallmark of an amateur programmer. It is a general
principle that an application spends 80% of the time on 20% of the code
(this isn't an absolute
Sunday, December 4, 2005 Ian Lynch wrote:
That depends on the size of the file. In fact compression can actually
speed up opening a file. Disc to RAM is slow but processes in RAM are
fast so loading a compressed file from disc to RAM and then
decompressing entirely in solid state could
On 12/5/05, Randomthots [EMAIL PROTECTED] wrote:
Roger Markus wrote:
Same here. There's the moral issue as well of not supporting the
illegal
organization Microsoft that is damaging to the computer industry as a
whole. Buying their products only strengthens the monster. If they
were
Chad Smith wrote:
Windows' easy-to-use interface,
A second-generation copy.
Office's powerful business apps,
Fundamentally designed in the 80's. Word for DOS and Multiplan were
genuinely innovative (though, as I understand it, Word was developed
outside of Microsoft, and, for all I know,
John W. Kennedy wrote:
Chad Smith wrote:
Windows' easy-to-use interface,
A second-generation copy.
Office's powerful business apps,
Fundamentally designed in the 80's. Word for DOS and Multiplan were
genuinely innovative (though, as I understand it, Word was developed
Bullshit. As I've
Roger Markus wrote:
So - Rod - you're a politician then! Cool moves my friend!
ROTFL :) Salesman, actually. I've sold cars and ran a Radio Shack store
for a while.
1) Compliment your opponent (Interesting) and make them feel at ease by
saying that you agree with them (I agree with
Randomthots wrote:
Remember, this was a big file. 63,260 rows by 7 columns. That's 442,820
instances of the 80 bytes of taggage surrounding each cell (35 MB,
total) plus the tags at the start of each row (times 63,260) plus all
the header information. Apparently with 256 MB RAM I simply ran
On Fri, 2005-12-02 at 09:25 -0600, Randomthots wrote:
The problem is I don't know a good name for the category of sw that's a
calendar/pim/email such as Outlook or the old Lotus Organizer.
There are apps that work to do the same job. They just don't happen to
be all sipplied by one
On Fri, 2005-12-02 at 09:58 -0600, Randomthots wrote:
If I'm not actively concerned about cross-platform and/or
cross-application compatibility, then XML is mostly meaningless to me.
But anyone an use that argument about any feature of MSO 2003. I don't
need it so its no improvement over OOo.
Ian Lynch wrote:
On Fri, 2005-12-02 at 09:25 -0600, Randomthots wrote:
The problem is I don't know a good name for the category of sw that's a
calendar/pim/email such as Outlook or the old Lotus Organizer.
There are apps that work to do the same job. They just don't happen to
be all
Alexandro Colorado wrote:
Again people confusing email with calendar functionality, and actually
by calendar they mean backend support for a fat client distributed
calendaring system.
I'm not. I was sort of surprised when I read Chad's quote, ...lack of a
powerful e-mail application
On Fri, 02 Dec 2005 15:25:29 -, Randomthots
[EMAIL PROTECTED] wrote:
The backend server stuff is important, but it doesn't necessarily need
to have the OOo name on it. But even for just one guy on one computer,
Outlook offers more functionality and ease-
of-use than Evolution,
Ian Lynch wrote:
Linux, OOo, etc. is supposed to be good enough
It is for many people, it certainly is for me and a growing number of
others. I'm going to Spain for the second time in a couple of months
because they seem to think its good enough for them. It'll never be good
enough for
Chad Smith wrote:
Article entitled E-mail 'crucial' to future of desktop Linux
http://news.zdnet.com/2100-9590_22-5978465.html?tag=nl.e589
E-mail will be the most significant factor governing the uptake of Linux on
the desktop, according to a new study.
The Desktop Linux Client Survey
64 matches
Mail list logo
