On Dec 6, 11:27 pm, "Mike Goodwin" <[EMAIL PROTECTED]> wrote: > Are you using the default in memory tables for HSQLDB?
Yes. I agree that it's not really a fair test when hsqldb is running memory tables but it's not really a fair test to use cached tables either which have known performance problems in hsqldb. I heard these performance problems are going to be fixed in the upcoming 1.9 release. The h2 benchmark isn't fair either: 1. derby uses durable operations and none of the others do. 2. derby has a 4m cache by default, h2 has a 16m cache by default. 3. derby does index logging, h2 doesn't log index changes by default (i can be turned on for h2). 4. hsqldb is configured to use cached tables which have known performance problems. I should rerun the h2 benchmark with derby's durability turned off, with identical cache sizes, and with h2 index logging on so it's a fair test. The last time I tried it derby beat h2 on the h2 benchmark. I noticed something strange about the h2 benchmark results on the website. Almost all the time for the hsqldb results is in one test (BenchC: Transactions). If I subtract the one test result I get this: h2 : 20422 - 4359 = 16063 hsqldb : 88314 - 75438 = 12876 The h2 benchmarks use cache tables for hsqldb. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
