author | Junio C Hamano <gitster@pobox.com> | |
Wed, 13 Feb 2008 07:39:03 +0000 (23:39 -0800) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Wed, 13 Feb 2008 07:39:03 +0000 (23:39 -0800) | ||
commit | 75ad235c2e2a751cd9c4c064d19b10a88ff9efcf | |
tree | 52679fbc8618e6e099c78f9758ed4f8c9bd2d773 | tree | snapshot |
parent | 6c47d0e8f3983cff5bf633cb8e6f7ecfecf48db7 | commit | diff |
Revert "pack-objects: only throw away data during memory pressure"
This reverts commit 9c2174350cc0ae0f6bad126e15fe1f9f044117ab.
Nico analyzed and found out that this does not really help, and
I agree with it.
By the time this gets into action and data is actively thrown
away, performance simply goes down the drain due to the data
constantly being reloaded over and over and over and over and
over and over again, to the point of virtually making no
relative progress at all. The previous behavior of enforcing
the memory limit by dynamically shrinking the window size at
least had the effect of allowing some kind of progress, even if
the end result wouldn't be optimal.
And that's the whole point behind this memory limiting feature:
allowing some progress to be made when resources are too limited
to let the repack go unbounded.
This reverts commit 9c2174350cc0ae0f6bad126e15fe1f9f044117ab.
Nico analyzed and found out that this does not really help, and
I agree with it.
By the time this gets into action and data is actively thrown
away, performance simply goes down the drain due to the data
constantly being reloaded over and over and over and over and
over and over again, to the point of virtually making no
relative progress at all. The previous behavior of enforcing
the memory limit by dynamically shrinking the window size at
least had the effect of allowing some kind of progress, even if
the end result wouldn't be optimal.
And that's the whole point behind this memory limiting feature:
allowing some progress to be made when resources are too limited
to let the repack go unbounded.
builtin-pack-objects.c | diff | blob | history |