Hi Frank, Drew, since I'm at it right know:
Am Dienstag, den 11.09.2007, 21:28 +0200 schrieb Frank Schönheit - Sun Microsystems Germany: > > 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?> > > Unfortunately not. This would be the only change which *really* allows > to address a number of performance issues with the embedded HSQLDB. > Amongst others, closing data views or forms becomes unacceptably slow > (IMO) if the .odb exceeds a certain (relatively small) size limit. Also, > opening the connection becomes slower as the database and thus the .odb > grows. The only change to overcome this would be the single-file > backend, but there has been no progress at this. Will a single file make such a big difference? And why? > (Well, not to mention we will have a hell of argueing to do with our > ODF/standardization folks. They do not like the idea of having one of > our applications having a proprietary format, and it will be pretty > difficult to convince them that this is the only acceptable way to make > embedded HSQLDB *really* usable, performance-wise. But that's another > story.) > > >>>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. > > You know we introduced the "performance" keyword in IZ a few days ago, I > for the moment at least added it to the issue. Waiting a little while for the paste (or import) to finish would be less problematic if there would be a progress bar showing 1. the office is busy and 2. something is happening currently to the user. > > 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. > > There's nothing like this in the documents - not in those I know, at least. > > In general, embedded HSQLDB is our main focus. Probably not everybody > will sign this, but hey, we introduced this "all in one file" feature > with a big bang in 2.0, exactly because everybody said that exactly this > is the killer feature we need if we want to be taken seriously as > desktop database. In my understanding, nothing changed since we accepted > this premise, so "all in one file" - i.e. embedded HSQL - is the main focus. I could easily think of owering the workload when serializing the database to disc by having some sort of background task preparing the physical save by e.g. building up the DOM-model of the data or the like. Questions arising are when to do it and how to synchronize to the users actions. And if this really is the hot spot consuming time (I think so since it's the main difference between XML and binary files). And third if this would be an offcie task or belongs into HSQL itself. Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
