Marc Santhoff wrote:
Am Montag, den 29.10.2007, 01:23 -0400 schrieb Andrew Jensen:
One thing to keep in mind here is to watch out for having the same
indexes - although it looks as if in your case this would not do a big
change.
No not a big change at all in this case...but I'll keep common indexing
in mind.
I can't give you exact numbers but Derby is even worse in how it does
this, it appeared.
Interesting observation ... maybe it would be worth while telling the
JVM running HSQL to use more memory (or less, who knows ;).
Well, just how do I do that. If I open options and add this
-Xms32m -Xmx64m
to the java parameters then when Base starts to connect I get an error,
saying the the JRE is defective. I am using 1.0.6_03 has this changed
from 1.0.5?
So I set the environment variable then JAVA_OPTIONS = -Xms32m -Xmx64m
then -Xms48m -Xmx96m , -Xms64m -Xmx128m, -Xms32m -Xmx256m
No change...but maybe I am not doing that correctly. Well total memory
used by soffice went up some. Still allocating memory 128K at a time,
mostly.
In fact that is not the full picture of the HSQL embedded database.
Using OO.org 2.3 there is a new problem. Open and close that table
repeatedly and each time you do it gets slower, on the third pass it
took 57 seconds to go from the first to the last record and each time it
allocates a total amount of memory greater then the previous time.
This is the point where commiting the data from HSQL to file comes into
play (dunno if repacking to .odb is involved, I think so). That is one
main cause of coffee breaks using internal HSQL.
So next weekend, I have three days with the house completely to
myself..and I will try and get very precise, as precise as I can,
numbers for all this. Will it help, I don't know...but it seems to me
that if memory allocation is actually the problem then that is something
that can most addressed.
During the week I'll run some ideas for the actual tests to execute past
folks.
For evaluating the difference between HSQL and Derby the best would be a
setup with equal databases hosted on a local server, as said.
Well, that will be one comparison. But Derby in the current
configuration and HSQL file based jdbc connection might be even closer
for these purposes and that will be another comparison.
>From making some quick tests using internal HSQL vs. a MySQL 3.x server
on a local net I remember MySQL getting slow on network performance when
doing massive copy or select actions. That's where HSQL was a lot
faster. On some selects to MySQL base was really slow and XMySQL (an
elderly administration tool) was lightning fast.
And what would you chalk that difference up to I wonder?
Another issue coming to my mind: How much memory does your computer
have? Especially win xp is known to be rather slow when having too less
memory. Some observations you made and reported over the time I could
not reproduce at all when trying on a machine running win98se with 1GB
RAM.
I would love to see your numbers then. I'm not doubting them, not at
all, just would like to see something saying that someone is getting
some decent performance out of this. After all we are still talking
about small databases here, one of the biggest complaints about the
Access MDB file format was that it wouldn't get past a couple of Gig's
in size...not a few dozen Megs.
Actually I am sure it would be faster with more memory, as I am at the
low end of what would be acceptable. 640 Megs with 32 dedicated to video.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
