| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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)
|
| |
|
|
| |
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
|
| |
|
