1. 17 May, 2017 1 commit
  2. 17 Apr, 2017 1 commit
    • Jason Madden's avatar
      Make all classes new-style. (#160) · e714f515
      Jason Madden authored
      * Make all classes new-style.
      
      On PyPy, it's documented (http://pypy.org/performance.html#id3) that
      old-style classes are slow, and classes that derive from both old and
      new are especially slow. I checked with the PyPy devs on IRC today and
      they confirmed that's still true with the latest PyPy2 releases.
      
      Unfortunately, FileStorage was one such mixed class, as was Connection.
      
      Moving to new-style classes seems to have a positive impact in the
      benchmarks. Here's zodbshootout on PyPy2 5.7.1 against a
      FileStorage (running in --threads and with 5 reps to be sure we get
      warmed up). First, current ZODB:
      
      "Transaction",                fs
      "Add 1000 Objects",            31,738
      "Update 1000 Objects",         42,444
      "Read 1000 Cold Objects",      51,894
      "Read 1000 Hot Objects",       53,187
      "Read 1000 Steamin' Objects", 835,877
      
      And with this PR:
      
      "Transaction",                fs
      "Add 1000 Objects",             35,651
      "Update 1000 Objects",          54,906
      "Read 1000 Cold Objects",      103,484
      "Read 1000 Hot Objects",        84,721
      "Read 1000 Steamin' Objects", 2,112,095
      
      The tests that hit the storage extensively are notably faster, as are
      steamin and hot, Connection having been a mixed class.
      
      I ran all tests multiple times. The data files were removed between
      runs. There's some variation, but the new-style classes always seem
      better.
      
      For comparison, here's CPython 2.7.13:
      
      "Transaction",                fs
      "Add 1000 Objects",            19,531
      "Update 1000 Objects",         16,201
      "Read 1000 Cold Objects",      22,111
      "Read 1000 Hot Objects",       21,851
      "Read 1000 Steamin' Objects", 880,582
      
      Locally I've run the tests under 2.7 and they all passed.
      e714f515
  3. 14 Apr, 2017 1 commit
    • Jason Madden's avatar
      Speed up ZODB.blob.BushyLayout.oid_to_path on Python 3 (#161) · 3580ddd8
      Jason Madden authored
      Profiling (https://github.com/zodb/zodbshootout/pull/32/) showed that
      this method was the only blob-related method that showed up in a test
      of creating blobs, other than those that actually performed IO.
      
      With this change its total and cumulative time drops from 0.003/0.004
      to 0.001/0.002 in a small benchmark. Blobs created per second shows a
      small but consistent improvement.
      
      Before:
      
         ncalls  tottime  percall  cumtime  percall filename:lineno(function)
            100    0.005    0.000    0.005    0.000 {built-in method rename}
            100    0.004    0.000    0.004    0.000 {function BlobFile.close at 0x1080d3a60}
            200    0.003    0.000    0.004    0.000 blob.py:576(oid_to_path)
            101    0.003    0.000    0.003    0.000 {built-in method mkdir}
            100    0.002    0.000    0.002    0.000 blob.py:333(__init__)
            402    0.002    0.000    0.005    0.000 {method 'dump' of '_pickle.Pickler' objects}
              1    0.002    0.002    0.034    0.034 Connection.py:553(_store_objects)
            201    0.002    0.000    0.002    0.000 {built-in method stat}
           5633    0.001    0.000    0.002    0.000 {built-in method isinstance}
      
      After:
      
         ncalls  tottime  percall  cumtime  percall filename:lineno(function)
            100    0.005    0.000    0.005    0.000 {built-in method rename}
            101    0.005    0.000    0.005    0.000 {built-in method mkdir}
            100    0.004    0.000    0.004    0.000 {function BlobFile.close at 0x10636aa60}
            402    0.002    0.000    0.005    0.000 {method 'dump' of '_pickle.Pickler' objects}
            100    0.002    0.000    0.002    0.000 blob.py:333(__init__)
              1    0.002    0.002    0.035    0.035 Connection.py:553(_store_objects)
            201    0.002    0.000    0.002    0.000 {built-in method stat}
           4033    0.001    0.000    0.001    0.000 {built-in method isinstance}
         ....
            200    0.001    0.000    0.002    0.000 blob.py:576(oid_to_path)
      3580ddd8
  4. 11 Apr, 2017 8 commits
  5. 09 Apr, 2017 1 commit
  6. 08 Apr, 2017 10 commits
  7. 07 Apr, 2017 3 commits
  8. 02 Apr, 2017 2 commits
    • Jim Fulton's avatar
      Merge pull request #153 from navytux/y/fs-ro · 4fa93367
      Jim Fulton authored
      FileStorage: Report problem on read-only open of non-existent file
      4fa93367
    • Kirill Smelkov's avatar
      FileStorage: Report problem on read-only open of non-existent file · 30bbabf1
      Kirill Smelkov authored
      ... instead of silently creating empty database on such opens.
      
      Use-case for this are utilities like e.g. zodbdump and zodbcmp which
      expect such storage opens to fail so that the tool can know there is no
      such storage and report it to user.
      
      In contrast current state is: read-only opens get created-on-the-fly
      empty storage with no content, but which can be iterated over without
      getting any error.
      
      This way e.g. `zodbdump non-existent.fs` produces empty output _and_
      exit code 0 which is not what caller expects.
      30bbabf1
  9. 27 Mar, 2017 1 commit
  10. 21 Mar, 2017 2 commits
  11. 09 Mar, 2017 1 commit
  12. 19 Feb, 2017 2 commits
  13. 09 Feb, 2017 6 commits
  14. 08 Feb, 2017 1 commit