"Alex Riesen" [off-list ref] writes:
quoted
The current code for "diff-index --cached" reads the whole tree
into the index as stage #1 entries (diff-lib.c::run_diff_index),
and then compares stage #0 (from the original index contents)
and stage #1 (the tree parameter from the command line). Even
if you stop at the first mismatch, you would already have paid
the overhead to open and read all tree objects before even
starting the comparison.
But I don't have to pay for the overhead of comparing all
entries, if I can stop at first mismatch and exit with non-0.
Bench it if you doubt me.
I'd bet that the time spent in comparison between stages inside
index (and remember, you are not generating textual diff, only
comparing the SHA-1) is dwarfed by the overhead of populating
the stage #1 of the index with what is read from all the tree
objects.
On 12/8/06, Junio C Hamano [off-list ref] wrote:
quoted
quoted
The current code for "diff-index --cached" reads the whole tree
into the index as stage #1 entries (diff-lib.c::run_diff_index),
and then compares stage #0 (from the original index contents)
and stage #1 (the tree parameter from the command line). Even
if you stop at the first mismatch, you would already have paid
the overhead to open and read all tree objects before even
starting the comparison.
But I don't have to pay for the overhead of comparing all
entries, if I can stop at first mismatch and exit with non-0.
Bench it if you doubt me.
I don't question that the overhead of comparing is very much
unnoticable. It just that it surely isn't zero, and it will grow with
the size of repo (linearly, right?)... And I am sure that this
repo will _only_ grow (typical corporate project).
I'd bet that the time spent in comparison between stages inside
index (and remember, you are not generating textual diff, only
comparing the SHA-1) is dwarfed by the overhead of populating
the stage #1 of the index with what is read from all the tree
objects.
I already understood that. I just haven't found yet what can I do