Hi, > It it's not really a fair test to use cached tables either which have known > performance problems in hsqldb > 4. hsqldb is configured to use cached tables which have known performance > problems.
I believe it's quite common that tables don't fit in memory. If HSQLDB has a problem with that then it should be reflected in the benchmark result. Both H2 and HSQLDB support in-memory operation, the others do not. I believe this scenario is not all that common. From what I know, most people use persistent databases / tables. > The h2 benchmark isn't fair either: > 1. derby uses durable operations and none of the others do. Derby doesn't use completely durable operations. Maybe it uses 'a bit more durable operations', but I fail to see any value in that. See http://h2database.com/html/advanced.html#durability_problems Derby doesn't use FileDescriptor.sync() by default, it uses RandomAccessFile(.., "rwd" or "rws"). Even if it would use FileDescriptor.sync() (which it doesn't), that would still not always guarantee durability. I believe we already discussed that? Derby supports a testing mode (system property derby.system.durability=test), I tried that. Even if enabled, Derby is still less than half as fast as H2 in default mode. See also http://h2database.com/html/performance.html > 2. derby has a 4m cache by default, h2 has a 16m cache by default. The Derby setting and documentation says '4m' but it doesn't mean that Derby uses 4 MB of heap memory. See http://h2database.com/html/performance.html#performance_comparison - the memory usage is listed in the benchmark result. Derby uses 11 MB for the simple test case, 10 MB for BenchA, 8 MB for BenchB, 9 MB for BenchC. H2 uses 6 / 9 / 9 / 9 MB. > 3. derby does index logging, h2 doesn't log index changes by default (i can > be turned on for h2). That's true. Unfortunately it can't be turned off for Derby. H2 does automatically rebuild the indexes if required after a crash. For medium sized databases (up to 1 GB) this is not a problem as re-building the indexes doesn't take that long, and crashes are not that common. You can argue the recovery time for larger databases is important, but then the benchmarks are made for medium sized databases. So far there are no benchmarks for large databases. > Almost all the time for the hsqldb results is in one test (BenchC: > Transactions). Yes, this is described. "HSQLDB is very slow in the last test (BenchC: Transactions), probably because is has a bad query optimizer.". See http://h2database.com/html/performance.html#performance_comparison > With that one change HSQLDB still beats H2 convincingly. Sorry I fail to see how you came to this conclusion. As I wrote before Overall time taken HSQLDB: 155'263ms, H2: 71'275ms > The 1.8.x versions of HSQLDB have performance problems with cached tables. I heard it is going to be fixed in the 1.9 release. Good to know this will be fixed. I will test it as soon as it's released (beta or stable). I'm currently working on a new 'page store' for H2. I don't have any performance results so far, but I hope things will be about the same fast as before. Regards, Thomas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
