Hi, On Mon, Jun 3, 2013 at 12:51 PM, Thomas Mueller <muel...@adobe.com> wrote: > I was not talking about differences in hardware. I know using different > hardware will result in different numbers. > > I was worried about results would be different if you run one test alone > versus if you run all tests. That would indicate a problem in the > benchmark (framework) itself. > > But luckily, that doesn't seem to be the case.
OK, good. The fixture code tries to make sure that the previous repository instance is fully shut down before starting a new one, and the warm-up period built into the test suite should take care of any remaining startup artifacts. > Specially the SmallFileWriteTest seems slow with Oak. The problem doesn't > seem to be actual blob handling; the profiling result shows the bottleneck > is with the (few) nodes. If I change the blob size to 0 (that is, 100 > nodes with the same zero-length blob each, instead of 100 nodes with 10 KB > each), I get basically the same result, with both MongoMK and the Oak-Tar. > Maybe it's a first sign of slow "many child nodes"? At least the TarMK should have no problems with the 100 child nodes (see the Wikipedia import test results :-). Instead I assume (though haven't profiled in detail) that much of the time is going to the still unoptimized getEffectiveNodeType() calls in NodeImpl.internalSetProperty(). Optimizing that is on my TODO. BR, Jukka Zitting
