Hi Frank,
Frank Schönheit wrote:
Numbers are always a good thing.
http://wiki.services.openoffice.org/wiki/Logging_JDBC_Activity contains
a description how to log activities in the JDBC bridge of OOo, which
allows to get numbers for a certain class of problems. (And sometimes it
even allows to find reasons.)
OK - have that set up.
Besides that, and responding to your suggestions in your other mail in
the thread: I believe that systematic performance tests/evaluations need
more background on the topic than I currently have. Saying that action X
needs Y seconds to finish is probably useless without describing the
environment in a defined, reproducible way. This doesn't mean numbers
themselves are useless (if Y is (even only felt to be) large enough,
then it should be investigated), but a systematic approach might need
more than this.
Agreed - numbers without context are not particularly useful - which
brings me to ask:
What exactly is the target scenario for the embedded database? ( treat
that as rhetorical for the moment, please )
Startup time is bad
Here, we probably should distinguish between a "cold start" (which
requires starting the JVM) and a hot start.
Nonetheless, numbers and an issue are helpful.
[CHUCKLING] - well, yes that is true. IF you are running quickstarter
under windows then opening the second and subsequent databases is faster
then the very first one.
Also, this is about embedded databases only, file based or server (
external processes from OOo main process ) based databases open
acceptably quickly, IMO.
For example, the File based HSQL driver opens databases much more
quickly then the current embedded model. Speaking of which, I seem to
recall that there was a Google
SOC project proposal for a change to the file structure of the HSQLdb to
address this problem ( among others ), if memory serves correctly it was
not picked up.
Have you heard anything further from the HSQLdb folks about this change?
Copy / Paste as a means to transfer data into Base is horrendous
Ehm - yes. Not sure if there exists an issue for this, yet.
There is, Issue 76606.
Not strictly, ATM. You can see at
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?logon=true&Id=3218
that there was a time were addressing those was considered a high
priority, but we somehow lost it from the radar with a lot of other
important changes happening ...
I see that it is targeted for 3.0 - so this seems like a good time to
start getting you some of those numbers to work with.
Yes. I'm biased how near we are to that point - for judging this, the
above-mentioned accumulated annoyance might be an indicator.
So then, back to the rhetorical question above.
What is (are) the target database(s) for performance testing? I suppose
that should be phrased as -
What are the use cases to be tested for performance purposes?
Reading over the design specifications I am at a loss to answer that
question, or at least at a loss to
finding anything in the specifications regarding this. Perhaps once
again I have failed to read carefully
enough however.
Alright - now I do not mean for this to be a bash Base exercise, rather
a 'How can we help discussion'.
For example - As i mentioned above I have the JDBC logging support
turned on now. Are there any use case
scenarios you would like to see numbers on? What kind of triage would
you like to see done on those raw numbers?
Let me know how I, or others, can help.
Sincerely,
Drew Jensen
ps - I failed to get back regarding the search I described earlier in a
10,000 record table under MS ACCESS 2007.
With or without field formatting being turned on the search takes less
then 2 seconds.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
