[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] Making RevCommit object representation more compact in memory
|
On Fri, Oct 8, 2010 at 12:43 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
> The C Git folks have speculated that another way to handle this is
> to assign each object an integer when it is allocated, and then
> have look-aside tables that are indexed by the object integer to
> store things like the parent data.
I quickly put together an RFC patch that shows this idea a little better:
http://egit.eclipse.org/r/1716
Improved docs, unit tests, and perf tests to show no regression are
necessary before I would be willing to submit this. It has an
increase in memory usage for topo sorting, we now need 8 bytes per
commit instead of 4 to do the topo sorting. But we can discard 4 of
those bytes as soon as the topo ordering is done, and we gain some
better application flexibility. It might be feasible for applications
like the PlotWalk to stop subclassing RevCommit and instead use a
DenseRevAnnotation.
--
Shawn.
