Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix built-in rebase perf regression #72

Closed

Conversation

dscho
Copy link
Member

@dscho dscho commented Nov 8, 2018

In our tests with large repositories, we noticed a serious regression of the performance of git rebase when using the built-in vs the shell script version. It boils down to an incorrect conversion of a git checkout -q: instead of using a twoway_merge as git checkout does, we used a oneway_merge as git reset does. The latter, however, calls lstat() on all files listed in the index, while the former essentially looks only at the files that are different between the given two revisions.

Let's reinstate the original behavior by introducing a flag to the reset_head() function to indicate whether we want to emulate reset --hard (in which case we use the oneway_merge, otherwise we use twoway_merge).

Changes vs v1:

  • More error paths are not consolidated via goto leave_reset_head.
  • The desc array is not initialized to all-zero, to avoid bogus addresses being passed to free().
  • The detach_head and reset_hard parameters have been consolidated into a flags parameter.
  • The reset_head() function once again only initializes head_oid when needed.

@dscho
Copy link
Member Author

dscho commented Nov 9, 2018

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 9, 2018

Submitted as pull.72.git.gitgitgadget@gmail.com

The same clean-up code is repeated quite a few times; Let's DRY up the
code some.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Currently, we only accept the flag indicating whether the HEAD should be
detached not. In the next commit, we want to introduce another flag: to
toggle between emulating `reset --hard` vs `checkout -q`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When we converted a `git checkout -q $onto^0` call to use
`reset_head()`, we inadvertently incurred a change from a twoway_merge
to a oneway_merge, as if we wanted a `git reset --hard` instead.

This has performance ramifications under certain, though, as the
oneway_merge needs to lstat() every single index entry whereas
twoway_merge does not.

So let's go back to the old behavior.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho force-pushed the builtin-rebase-perf-regression branch from 070092b to a7360b8 Compare November 12, 2018 11:20
@dscho
Copy link
Member Author

dscho commented Nov 12, 2018

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 12, 2018

Submitted as pull.72.v2.git.gitgitgadget@gmail.com

@gitgitgadget

This comment has been minimized.

@gitgitgadget

This comment has been minimized.

@gitgitgadget

This comment has been minimized.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 15, 2018

This branch is now known as js/builtin-rebase-perf-fix.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 15, 2018

This patch series was integrated into pu via git@bb6dd0e.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 15, 2018

This patch series was integrated into next via git@bb6dd0e.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 15, 2018

This patch series was integrated into master via git@bb6dd0e.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 15, 2018

This patch series was integrated into maint via git@bb6dd0e.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 15, 2018

Closed via bb6dd0e.

@gitgitgadget gitgitgadget bot closed this Dec 15, 2018
@dscho dscho deleted the builtin-rebase-perf-regression branch December 15, 2018 21:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant