• Tim Peters's avatar
    Merge rev 37432 from 3.4 branch. · a138c76e
    Tim Peters authored
    The cache simulation seems good enough to be useful now,
    although the toy app I wrote to generate a 500MB trace
    file doesn't use MVCC in an essential way (some of the
    MVCC simulation code is nevertheless exercised, since
    an invalidation of current data in the presence of MVCC
    always creates a cache record for the newly non-current
    revision).
    
    Still puzzling over what to do when the trace file records
    a load hit but the simulated cache gets a miss.  The
    old simulation code seemed to assume that a store for the same
    oid would show up in the trace file next, and it could get
    the info it needed about the missing object from the store
    trace.  But that isn't true:  precisely because the load was
    a hit in the trace file, the object isn't going to be stored
    again "soon" in the trace file.
    
    Here are some actual-vs-simulated hit rate results, for a
    20MB cache, with a trace file covering about 9 million
    loads, over 3 ZEO client (re)starts:
    
    actual   simulated
    ------   ---------
      93.1        92.7
      79.8        79.0
      68.0        69.1
          
      81.4        81.1  overall
    
    Since the simulated hit rates are both higher and lower
    than the actual hit rates, that argues against a gross
    systematic bias in the simulation (although there may
    be several systematic biases in opposite directions).
    a138c76e
cache.py 41.6 KB