Patches: Modifications to org.h2.store.DiskFile.java and org.h2.util.BitField.java
Reason: Makes some things faster. If you haven't poked into the code in depth, that's all you need to care about. Changes: Improved performance on file allocation-related tasks (BitField changes) -- setRange method is *much* faster, should let H2 more quickly mark file blocks as used/unused/etc -- other tweaks should provide minor performance improvements where BitField is used Improved performance on DiskFile.initFromSummary / getSummary -- in one test, this is 4x faster -- this should (in theory) improve performance on some logging / checkpoint and shutdown/close DB Benchmarks (using repository version as of about July 28): Before patch : 23275 and 31407 statement/sec After patch: 23564 and 32854 statement/sec Slight performance improvements, but not bad for micro-optimizations. The difference is much more noticeable if you just compare times for the changed methods, not overall. Disk I/O is so much slower than other things (especially on my system) that it hides the impact of the optimizations. As per build page requirements: * Does not use JRE 1.6 features * Passes checkstyle * Passes unit tests, does not appear to add any new issues with performance testing or basic running of "build test" * Existing coverage includes changed code, no new tests needed * No changes to documentation required * License statement below as required by new patch submission rules Statement for contributions (not significant, in my opinion, but I'd just covering my bases): I wrote the code, it's mine, and I am contributing to H2 for distribution multiple-licensed under the H2 license, version 1.0, and under the Eclipse public license, version 1.0 Link: http://www.h2database.com/html/license.html >From now on, I apply this to all posts to this newsgroup or emails to Thomas Mueller unless otherwise stated. I'm submitting these patches for the second time now. I first submitted by email, now I'm following the modified procedure. My email version had slightly different code for the BitField.setRange method -- the new version *may* be faster, and is functionally the same. It is fully free (I believe) of potential issues from similarity to the java.util.BitSet library class, as I have rewritten sections that worried me. The old version should still be okay too. I also merged the last few days of commits. The emailed code was as fully tested as possible. The modified BitField.setRange has not gotten this testing, because some hateful thing in the build process or project structure broke when I updated with the latest commits. Eclipse says files are missing, SVN won't add in new files from the repo, and I'm out of patience to fix this until tomorrow. I just want to get my patch in before there are additional changes to merge -- new problems will show up in the autobuild and unit tests, anyway. Probably I'll figure it out tomorrow. ** Other things I've noticed: ** Allocation routines aren't always optimal -- I think that some of the allocate routines are doing linear scans of the whole block allocation table to find free space. This is fine for small files (I/O matters more, scanning a BitField or IntArray is fast) but poses performance problems with big DBs. Will verify. String read/write is slow because it has to read every character and count the bytes it needs to encode to/from. If the length in encoded bytes were stored along with # of characters, strings could be read or skipped in single operations. Regards, Samuel Van Oort --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
bitfield.patch
Description: Binary data
h2_diskfile_patch.patch
Description: Binary data
