-
Notifications
You must be signed in to change notification settings - Fork 649
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
GitVersion newer than v3.4.1 has severe performance problems #1066
Comments
If you roll back to GitVersion 3.4.1 does the performance improve? |
3.6.3 ran for 24.2 minutes |
Should we be rolling back to 3.4.1? |
@roryprimrose: If you don't need any of the features or bug fixes implemented by 3.4.1+, then by all means downgrade until we figure this one out. 😃 Caching has been a repeated issue, but usually the other way around since we implemented it in #737; people have complained about the cache being too eager and not being able to invalidate it. So a lot of stuff has happened around cache invalidation lately that I guess affects you in unexpected ways. If you have a look at this search for "cache", you can see that there has been done a lot of stuff related to caching, so any one of those pull requests can be the source of your troubles. The diff between 3.4.1 and 3.6.3 is too big to list on GitHub, so I guess wading through the swathes of commits is going to be too much work, but the source of your problems is hidden in there somewhere. 😄 |
I've been able to narrow it down a little. I've incrementally updated each version and pushed builds. The build against 3.5.4 took 10 minutes. Updating to 3.6.0 took 24 minutes. The following is a view of the GitVersionTask executing for just one of the projects in the solution. The execution time goes from 14 seconds to 57 seconds. 3.5.4
3.6.0
|
I've tested some additional versions. 3.6.0, 3.6.1, 3.6.2 and 3.6.4 all have this performance issue. I didn't test 3.6.3 as there seemed to be little point. |
The reasoned I specifically mention 3.4.1 is that I thought the following versions have a dependency on a version of libgit2sharp has has some slow debugging code, and wasn't sure if the issues you were having was related to that or an actual caching issue. Since 3.5.4 is performing similar, maybe the dependency was introduced then. The current support branch has an update to use the latest libgit2sharp package without the debug code. |
@discomurray: What slow debugging code are you referring to? If that's indeed the case, you might be on to something. |
see this issue in libgit2sharp libgit2/libgit2sharp#1368 |
@discomurray: Ah, thanks for the pointer. Is it worth hoping that @mkoertgen's work in #1024 might help on the performance issue (as well), then? |
At least the version of libgit2 matches, so probably yes. |
We downgraded for a few weeks to avoid the perf issues, but had to go back to 3.6.4 to get pull request id values in the version. Builds are back to > 20 minute builds. :( |
@roryprimrose In 3.6.0 and 3.6.1, the caching of information was broken (#942). Could this be part of the problem you are seeing? Do you have separate repositories for each project or are they shared? |
If the caching was fixed after 3.6.1 then no as we are back up to 3.6.4. We have a repository per solution under the one VSTS account. |
@roryprimrose Ok, the bug was that the caching didn't work at all, so if you ran GitVersion multiple times in the same repository (without anything changing), the cache did not work. I added some in-memory caching as PR #1100. You can try that via the newest beta release and see if it helps. Note that the configuration syntax has slightly changed, if you use a custom configuration. |
@DanielRose |
@tebeco It is part of the current pre-release, v4.0.0-beta.9 |
@DanielRose I updated to 4.0.0-beta0009 and our build still took 24 minutes. :( |
Can you post a current log? |
Sorry, had to move this comment to a gist because it was too long. See https://gist.github.com/roryprimrose/13b0d32dec9b8dc0e9e859166f3d0f95 |
Looking at the log: The cache is hit for the second project because it is in the same directory ( Looking at the log (first project), the relevant lines are:
Finding the branch configuration to use took 0.6s. There is no configuration for the branch, and the default is now Inherit, i.e. use the configuration of the parent branch. Calculating the data for the version numbers took 2.1s. The problem is right at the start (and it also exists in the second project BTW): Right at the beginning there is a 20 second pause. What happens there is a call to |
@roryprimrose I added some more logging as PR #1116. Looking at what That data is normally in your
Since that call takes so long every time, I'm assuming that is getting cleaned up again somewhere. As an alternative solution, see if you can configure your build server to fetch all data instead of only the required branch. |
@DanielRose There is no configuration in our build that I am aware of that would clean the git repository and we are already getting the full repository before running the msbuild step. We are using a local build agent so the VM is not being refreshed on each build. The only clean we have is a build step that wipes out the following from the build sources directory.
Our build starts and ends with the build steps from https://marketplace.visualstudio.com/items?itemName=ioz.vsts-git-build-tasks that give access to the report repository. The build then runs the following before the msbuild step as per #993
|
We just tried GitVersionTask 4.0.0-beta0009 and it still has the same perf issues for us. Build ran for 24.5 minutes. |
I've posted my workaround at http://www.neovolve.com/2017/02/01/gitversiontask-performance-workaround/. It has dropped our build time from 28 minutes back down to 12.5 minutes |
The performance is pretty horrific on our repo too. Anything between 7 -> 15 minutes. Weirdly depends on what branch we're on etc. This is starting to be a showstopper for us. |
@kyberias: Have you tried @roryprimrose's workaround? |
"The workaround was to get most of the projects in the build to not run GitVersionTask." I fail to see how that would help. It seems GitVersion just keeps scanning the repo branches and commits for 7 to 15 minutes. We're running GitVersion.exe command line once in the build for the repository, not for each individual project. Or does GitVersion somehow look at all the projects and repeat? |
If removing GitVersionTask from a project is a workaround, it points to the caching not working as intended. The version should only be calculated once for the first compiled project in a solution, cached to disk and then read from cache on subsequent project builds. Is this not happening? How does the GitVersion log look like? |
Does GitVersion work as intended if it calculates the version for 7 to 15 minutes (with or without cache)? I cannot share the log here for obvious reasons. What should the log look like? I may need to check whether we have some issues with the cache. If TFS build always cleans git, I guess that will clear up the cache as well? |
The log should contain lines mentioning a GitVersion/src/GitVersionCore/GitVersionCache.cs Lines 10 to 111 in 6d90d26
|
(edited out / sorry i now understand my comment was a bit too direct) |
For what it's worth I'm using the latest version on Chocolatey - 3.6.4, and it works fine on my development machine, seconds to run. But as soon as I push my changes and ask Bamboo to build it it fails as it takes too long. Command line on our Bamboo server in the build-dir and GitVersion takes minutes to run. Seems to be environmentally affected. |
So further to my last comment I can say that the Bamboo server randomly takes a long time. Around 3 minutes, other times it's instant (ish). |
@tebeco: The project is not abandoned. I believe the work @JakeGinnivan has started on in #1243 and #1244 will solve most performance problems. The only problem is that it's a massive task to recreate all of LibGit2Sharp's models and map them into GitVersion's own internal (immutable, in-memory) model. If anyone experiencing this can provide help with moving either of those pull requests, it would be highly appreciated. |
But the first PR was updated last summer (in June!) and the other PR hasn't been touched in months. It may have not been abandoned totally, but clearly these issues have no priority and/or lack of resources. |
We do have a lack of resources. For most people, myself included, GitVersion seems to do what it should without a problem. It is therefore difficult to muster the energy to spend our free time to scratch an itch we don't have ourselves. This is a community driven project with no financial backing, so the best thing we can hope for is for someone who has this itch to come along and figure out the problem and submit a pull request. If someone involved in this issue thread can do just that, us maintainers would be thrilled to review and merge it. |
There should be mandatory community service (via contributing PR's) for people who complain about the speed and priority that other people give to open source. |
@roryprimrose, oh I agree. I'm not complaining about speed per se, I'm merely saying that it's not fair to answer to criticism about "project abandonment" with links to PRs that haven't been touched for a year! My specific performance problem (#1327) seems to be related to Gitversion getting confused and going crazy due to a large number of (feature) branches without a naming convention. |
Seeing how deep you have dug to figure out the source of this problem already, @kyberias, would you be up for trying to figure out a solution? As mentioned, I would be thrilled to review and merge any optimization you're able to conjure in a PR. |
Thanks for responding. I couldn't find enough time to do further investigations but it seems some months ago our team was able to solve most drastic GV performance problems by updating to final 4.0.0 version. It's still not super fast but but at least keeps quite stable. |
I'm glad to hear that. If you experience problems with GitVersion again, access to a repository where the problem can be reproduced or a PR that fixes the problem will be highly appreciated. |
We use GitVersionTask (3.6.3) on all the projects in a solution to ensure that all deployed assemblies reflect the correct version from a build (local or build agent). Something has happened in our git branching whereby GitVersionTask for a project has now gone from ~10 seconds to run WriteVersionInfoToBuildLog, UpdateAssemblyInfo and GetVersion to ~60 seconds.
This is a big issue for us because there a 16 projects in the solution that use GitVersionTask. Our overall build time has just jumped from 8 minutes to 18-24 minutes.
Is it possible for GitVersionTask to cache the calculation of version metadata and share this between the projects being built? Re-calculating the same information on each project build is very expensive.
The text was updated successfully, but these errors were encountered: