3 ms·
> have blazing fast performance Sorry, but GitLab has never been blazing fast. The gitlab.com instance is notoriously slow — supposedly improved a lot over the
by oefrha 7y ago
> have blazing fast performance
Sorry, but GitLab has never been blazing fast. The gitlab.com instance is notoriously slow — supposedly improved a lot over the past few years, but still feels pretty sluggish. My self-hosted instance isn’t much better.
In fact, a couple of open source maintainer friends looked into migrating to GitLab when GitHub was acquired by MS; they did not precisely because GitLab was too slow.
- frant-hartm 7y agoFrom my experience a custom GitLab instance is much faster that GitHub.com. But it is apples and oranges and I suppose your friends weren't comparing the two.
- oefrha 7y agoMy custom GitLab instance is still slower than github.com. (Yes, I’m giving it enough memory.)
- Aeolun 7y agoIt’s slower than github.com, but I wouldn’t call it slow. What’s slow is out bitbucket datacenter edition.
- lbotos 7y agoIf you are a customer you can file a support ticket and our Support Engineers can help troubleshoot. One of our mandates is "performance is a feature" and we want to better understand what's happening in the wild. If not, and you are interested, we built a tool we use called "fast-stats": https://gitlab.com/gitlab-com/support/toolbox/fast-stats https://gitlab.com/gitlab-com/support/toolbox/fast-stats it might be able to pinpoint what controllers are slow for your own curiosity.
- oefrha 7y agoI'm a community user, and the sluggishness seems to be a common sentiment so I'm not sure profiling my instance will add anything valuable that's not already known. (Sorry if my comments sounded entitled.)
- 1337shadow 7y agoLet me clarify: git clone/fetch/push on gitlab.com or github.com is sluggish, but on my private instances it's blazing fast, because I get great and un-metered bandwidth from my dedicated servers which might not be the case for everybody / every country. Another thing: CI starts the very second I push, and since I configure dedicated runners extremely well GitLab makes it easy keep every pipeline stage under 5 minutes, which is critical to me, as such I recon I have acquired countless tricks for that matter. Also, the ChatOps integration (GitLab to Mattermost or Slack) seems instant for me. Those factors matter for me because I'm an extremely fast iterator and often iterate on several repositories at the time. The cherry on the top is that the mirroring between my gitlab instance and github is also blazing fast. As for the web interface, well they all feel slow to me so I don't spend my time waiting for them so it's ruled out of the equation for me anyway, I'm just far more comfortable with command line anyway. But, pushing to gitlab prints out the URL to create a pull request from that branch, or to view the existing one, also a time saver that's not available on github, not sure why though.
- mcny 7y agoYou should look into git request-pull. I haven't gotten it to work but I'm probably doing it wrong. It should work. https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull
- chriscool 7y ago> pushing to gitlab prints out the URL to create a pull request from that branch You can use push options to automatically create a pull request and set it up when you push: https://docs.gitlab.com/ee/user/project/push_options.html https://docs.gitlab.com/ee/user/project/push_options.html
- AdamJacobMuller 7y agoHad no idea that existed, super cool, thanks!
- oefrha 7y ago> pushing to gitlab prints out the URL to create a pull request from that branch, or to view the existing one, also a time saver that's not available on github IIRC I’ve seen that recently with GitHub too. Not very useful to me though since I use magit for almost all git-related operations.
- erikbye 7y agoNot to mention consuming way too much memory. I prefer Gitea, or cgit if I need even less features.
- 1337shadow 7y agoIndeed, you can use drone-CI with Gitea that's also an option. But for now I find Gitlab-CI still slightly better: graphical representation of the pipeline, editable environment variables, review-stop jobs to clean up review deploys, automatic review-stop on MR merge ... Anyway, I run both because some people really want to keep their main repo activity on GitHub "for visibility" (for me that doesn't stand: I use gitlab->github mirroring feature as such my work is still published on github)