| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Miguel Molina <miguel@erizocosmi.co>
|
| |
|
|
|
|
|
| |
Loading from an on-disk idxfile will usually already have the idxfile
entries in order, so check that before wasting time on sorting.
Signed-off-by: David Symonds <dsymonds@golang.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a map for offset indexing, use a sorted slice.
Binary searching is fast, and a slice is much more compact.
This has a negligible hit on speed, but has a significant impact on
memory usage, especially for larger repos.
benchmark old ns/op new ns/op delta
BenchmarkIndexConstruction-12 15506506 14056098 -9.35%
benchmark old allocs new allocs delta
BenchmarkIndexConstruction-12 60764 60385 -0.62%
benchmark old bytes new bytes delta
BenchmarkIndexConstruction-12 4318145 3913169 -9.38%
Signed-off-by: David Symonds <dsymonds@golang.org>
|
|
|
There was an internal type (i.e. storage/filesystem.idx) to
use as in-memory index for packfiles. This was not convenient
to reuse in the packfile.
This commit creates a new representation (format/packfile.Index)
that can be converted to and from idxfile.Idxfile.
A packfile.Index now contains the functionality that was scattered
on storage/filesystem.idx and packfile.Decoder's internals.
storage/filesystem now reuses packfile.Index instances and this
also results in higher cache hit ratios when resolving deltas.
|
