aboutsummaryrefslogtreecommitdiff
path: root/diffcore-delta.c
Commit message (Collapse)AuthorAge
* Merge branch 'tk/diffcore-delta-remove-unused'Junio C Hamano2016-11-17
|\ | | | | | | | | | | | | Code cleanup. * tk/diffcore-delta-remove-unused: diffcore-delta: remove unused parameter to diffcore_count_changes()
| * diffcore-delta: remove unused parameter to diffcore_count_changes()Tobias Klauser2016-11-14
| | | | | | | | | | | | | | | | | | | | | | The delta_limit parameter to diffcore_count_changes() has been unused since commit ba23bbc8e ("diffcore-delta: make change counter to byte oriented again.", 2006-03-04). Remove the parameter and adjust all callers. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | use QSORTRené Scharfe2016-09-29
|/ | | | | | | | | Apply the semantic patch contrib/coccinelle/qsort.cocci to the code base, replacing calls of qsort(3) with QSORT. The resulting code is shorter and supports empty arrays with NULL pointers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* use st_add and st_mult for allocation size computationJeff King2016-02-22
| | | | | | | | | | | | | If our size computation overflows size_t, we may allocate a much smaller buffer than we expected and overflow it. It's probably impossible to trigger an overflow in most of these sites in practice, but it is easy enough convert their additions and multiplications into overflow-checking variants. This may be fixing real bugs, and it makes auditing the code easier. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix diff -B/--dirstat miscounting of newly added contentsLinus Torvalds2009-12-05
| | | | | | | | | | | | | | | | | | | | | | | What used to happen is that diffcore_count_changes() simply ignored any hashes in the destination that didn't match hashes in the source. EXCEPT if the source hash didn't exist at all, in which case it would count _one_ destination hash that happened to have the "next" hash value. As a consequence, newly added material was often undercounted, making output from --dirstat and "complete rewrite" detection used by -B unrelialble. This changes it so that: - whenever it bypasses a destination hash (because it doesn't match a source), it counts the bytes associated with that as "literal added" - at the end (once we have used up all the source hashes), we do the same thing with the remaining destination hashes. - when hashes do match, and we use the difference in counts as a value, we also use up that destination hash entry (the 'd++'). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* optimize diffcore-delta by sorting hash entries.Linus Torvalds2007-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here's a test-patch. I don't guarantee anything, except that when I did the timings I also did a "wc" on the result, and they matched.. Before: [torvalds@woody linux]$ time git diff -l0 --stat -C v2.6.22.. | wc 7104 28574 438020 real 0m10.526s user 0m10.401s sys 0m0.136s After: [torvalds@woody linux]$ time ~/git/git diff -l0 --stat -C v2.6.22.. | wc 7104 28574 438020 real 0m8.876s user 0m8.761s sys 0m0.128s but the diff is fairly simple, so if somebody will go over it and say whether it's likely to be *correct* too, that 15% may well be worth it. [ Side note, without rename detection, that diff takes just under three seconds for me, so in that sense the improvement to the rename detection itself is larger than the overall 15% - it brings the cost of just rename detection from 7.5s to 5.9s, which would be on the order of just over a 20% performance improvement. ] Hmm. The patch depends on half-way subtle issues like the fact that the hashtables are guaranteed to not be full => we're guaranteed to have zero counts at the end => we don't need to do any steenking iterator count in the loop. A few comments might in order. Linus
* Introduce diff_filespec_is_binary()Junio C Hamano2007-07-06
| | | | | | | | | | | This replaces an explicit initialization of filespec->is_binary field used for rename/break followed by direct access to that field with a wrapper function that lazily iniaitlizes and accesses the field. We would add more attribute accesses for the use of diff routines, and it would be better to make this abstraction earlier. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* diffcore-delta.c: Ignore CR in CRLF for text filesJunio C Hamano2007-06-30
| | | | | | | | | | | | This ignores CR byte in CRLF sequence in text file when computing similarity of two blobs. Usually this should not matter as nobody sane would be checking in a file with CRLF line endings to the repository (they would use autocrlf so that the repository copy would have LF line endings). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* diffcore-delta.c: update the comment on the algorithm.Junio C Hamano2007-06-30
| | | | | | | | | | The comment at the top of the file described an old algorithm that was neutral to text/binary differences (it hashed sliding window of N-byte sequences and counted overlaps), but long time ago we switched to a new heuristics that are more suitable for line oriented (read: text) files that are much faster. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* diffcore_count_changes: pass diffcore_filespecJunio C Hamano2007-06-30
| | | | | | | | | | We may want to use richer information on the data we are dealing with in this function, so instead of passing a buffer address and length, just pass the diffcore_filespec structure. Existing callers always call this function with parameters taken from a filespec anyway, so there is no functionality changes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* diffcore-delta: 64-byte-or-EOL ultrafast replacement (hash fix).Linus Torvalds2006-03-15
| | | | | | | The rotating 64-bit number was not really rotating, and worse yet ulong was longer than 64-bit on 64-bit architectures X-<. Signed-off-by: Junio C Hamano <junkio@cox.net>
* diffcore-delta: 64-byte-or-EOL ultrafast replacement.Linus Torvalds2006-03-15
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* diffcore-delta: tweak hashbase value.Junio C Hamano2006-03-12
| | | | | | | | | This tweaks the maximum hashvalue we use to hash the string into without making the maximum size of the hashtable can grow from the current limit. With this, the renames detected becomes a bit more precise without incurring additional paging cost. Signed-off-by: Junio C Hamano <junkio@cox.net>
* diffcore-delta: make the hash a bit denser.Junio C Hamano2006-03-12
| | | | | | | | To reduce wasted memory, wait until the hash fills up more densely before we rehash. This reduces the working set size a bit further. Signed-off-by: Junio C Hamano <junkio@cox.net>
* diffcore-rename: somewhat optimized.Junio C Hamano2006-03-12
| | | | | | | | | This changes diffcore-rename to reuse statistics information gathered during similarity estimation, and updates the hashtable implementation used to keep track of the statistics to be denser. This seems to give better performance. Signed-off-by: Junio C Hamano <junkio@cox.net>
* diffcore-delta: make change counter to byte oriented again.Junio C Hamano2006-03-04
| | | | | | | | The textual line oriented change counter was fun but was not very effective. It tended to overcount the changes. This one changes it to a simple N-letter substring based implementation. Signed-off-by: Junio C Hamano <junkio@cox.net>
* diffcore-rename: split out the delta counting code.Junio C Hamano2006-02-28
This is to rework diffcore break/rename/copy detection code so that it does not affected when deltifier code gets improved. Signed-off-by: Junio C Hamano <junkio@cox.net>