|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.
Back to the top