| Age | Commit message (Collapse) | Author |
|---|
|
Needs plenty of work
|
|
tests only work reliably in a patched up version, or the next point release.
|
|
implemented now - depending on the performance, it might actually receive some more work
|
|
least, which implicitly includes pack handling. For the pack specific tests to work, one would need a pack interface though, which is currently not planned to be specifically exposed
|
|
optimal results in all cases (at least the ones I can test)
pack: now works properly with a sliding memory manager
test_packedodb_pure: fixed very memory hungry implementation by using an iterator. This will of course reduce the measured performance a bit, but 750MB of memory is just a little bit too much for an ordinary test. Maybe it would be alright to just reduce the number of items ... but performance isn't a strength of python after all
|
|
fast with nearly now overhead if the data streams in fast enough (~30 MB/s when writing a pack). This shows that there is huge potential for sending packs, considering that we are actually recompressing them (without deltification). To be faster in future, we could probably just send ref-deltas or full objects as found in the pack without doing any recompression.
|
|
database (as streams have to be decompressed, it should be redesigned to have multiple database implementations)
|
|
indicate what it tests
|
|
|
|
command implementations. The previous performance test was truncated a bit as it compared directly with the git hash_object write performance. This is out, and if we wanted it we could implement it , but its actually slower for us
|
|
be tested as well at some point
|
|
future implementations to use the test as well
|
|
|
|
changed drastically. Now the actual work begins
|
|
|
|
Then the tests will need some work
|
|
adjusted
|
