Hacker News Reader

Comment by ploggingdev | Hacker News Reader

The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanely fast, compared to a few months ago where loading commit messages in the UI used to take at least a couple of seconds. I don't follow gitlab development too closely, but they seem to have focused a lot on improving cache performance.

But one change that I did not like was the the removal of the side panel which could be pinned. Navigation required fewer steps, but now an extra click is required to bring up the options.

View on HN

Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk...

There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV...

And the git access timings are a sea of red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTz...

Git access will be improved now that we have Gitaly as part of this release. In GitLab 9.1 we want to move git access from the application server to the file server. That should greatly reduce the latency.

Can't access any of those links, just get a login prompt.

That is the internal one, Sid meant to link to the public monitoring, located at http://monitor.gitlab.net/. It doesn't have the daily overview dashboard, but the fleet overview might be an indicator too (http://monitor.gitlab.net/dashboard/db/fleet-overview).

Sorry about that, we've replaced the links with screenshots.

The problem is that we can't measure Unicorn timings with Prometheus since it is multi-process. Our Prometheus team is working to fix this for everyone.

I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.

Speed is essential for a tool like GitLab that people use intensely. We've made great progress in having better monitoring to see what the cause is. For 9.1 we've scheduled many more performance improvements https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... than we were able to complete in 9.0 https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

What about memory usage?

Is Sublime really an editor of choice if speed comes first?

It's all relative... what kind of computer are you using, the cpu speed, memory available, even OS and drive/ssd can make differences. Even on an i7 with 32gb and an SSD atom was too slow for a really long time... in fact after trying earlier releases of atom and brackets, I almost didn't even try VS Code. I'm really glad I did though.

In any case, it's just a matter of relative performance and perception in relation to what one runs on, and their needs.

Well, compared to Atom, yes. Two somewhat similar tools with trade offs between them, one of them being speed.

Note that Atom is written in Javascript, so the run time is extraordinarily CPU heavy. Even though many Electron (Javascript desktop framework) apps may have snappy UIs, they're typically even worse than Java for CPU (battery life, etc).

btw: Sublime Text is written in C++, so the performance might be even better than Java.

What's a similar editor that's faster? VS Code?

Yes.

VSCode faster than Sublime? Are you sure of that?

VSCode is certainly nice and fast, but I've been able to do choke vscode a lot faster than Sublime.

Plus, you can't even open files above what, 100(?)mb in vscode whereas Sublime happily opens that in a snap.

No, I meant that VS Code, (which is similar to Atom in both features, technology used and price), is (much) faster than Atom, (Electron vs Electron), it is obviously not faster than Sublime, (Electron vs Native).

I understood the OP's question as what is similar to Atom, but faster, is it VS Code?

If speed really comes first, vi is probably similar enough.

Well isn't vi a bit bloated rendering irrelevant lines, shouldn't we just use ed?

Taking a look at Gitaly & the conversations around it, I don't see much in the way of consensus. Are you using Redis for the distributed lock or is this still a centralized system?

My query being you can effectively use the native pre-receive hooks & wrap the git shell to allow consensus without needing to replace git with an RPC system like Gitaly.

Gitaly is still a centralized system. It shards the git repositories over multiple git servers in one datacenter.

We looked into Git Ketch https://www.infoq.com/news/2016/02/google-kick-starts-git-ke... for a distributed system based on hooks. But this requires a sync per repository (very slow with 100k+ repos per server) and it is no longer actively being worked on by Google.

Next time you think about distributing git, you should take a look at the combination of jgit and a distributed key value store.

A little while ago I spent a night and I was able to get a fully distributed git http server up and running. I used HBase and was able to get it most things working. That allows the only contention to be around refs. Everything else is well distributed and spread across as many machines as you need. Caching is handled on the key value store side, and the http server side. I didn't get to git gc work though.

> That allows the only contention to be around refs.

This is solved without modifying the git client using a distributed/shared lock wrapping the git-shell & git-hooks (pre-receive) . If you were to modify the git server behavior to say use epaxos, one could provide even better latency guaranties https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf .

I'm not sure about the GC operation though, did you use the DfsGarbageCollector that is part of Jgit? I thought that was provided as part of the DFS interface.

http://download.eclipse.org/jgit/docs/jgit-2.0.0.20120613090...

Thanks for the reply.

There are plenty of off-the-shelf consensus algorithms/services you could use in the git-hooks that don't have the git-ketch limitation. Zookeeper, etcd, consule, redis, etc. It really just matters your criteria and requirements, they all of trade-offs but I'm sure one fits.

To be frank I think your time is better spent looking into why one of these consensus packages isn't the right call for your needs. Since they could easily plug into the git-hooks & git-shell commands, it could avoid a massive investment of time from your team and you.

> you can effectively use the native pre-receive hooks & wrap the git shell

The way GitLab is organized (pre-Gitaly) makes it very hard to do things like that. Roughly speaking, when handling a push, it is a coordinated dance between GitLab components to make sure it all goes in, but none of these components has full control over the push from start to finish. One of the reasons we are creating Gitaly is to create a 'place' (namely Gitaly) where we _can_ exercise such control.

The other big reason for building it is not having to use Git repos on NFS.

(Gitaly maintainer)

Looks like those last two screenshots are Grafana - do you mind sharing the dashboard JSON for those views? Very cool!

Thanks. Most of our monitoring is public on http://monitor.gitlab.net/ the things I showed are not because we're still working to make Prometheus work with multi process applications. I'm not sure the Json is public.

There's also http://arewefastyet.gitlab.com

Thanks for the feedback regarding the sidebar navigation! Here's the issue that we used to chat extensively about it and came to our current design here in 9.0: https://gitlab.com/gitlab-org/gitlab-ce/issues/26200

There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are actively listening to feedback and will continue to iterate.

We're working hard to improve usability and navigation in general. In addition to this sidebar change, we've made many nav updates: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348.

Trading usability for screen real-estate? Sounds like your designers have gone off the deep end and fail to realize that Gitlab is a productivity tool, not an art piece.

I'd argue that extra screen real estate for the content that matters often lends itself toward better UX, but any specific suggestions for improvements would be appreciated. :)

That's quite a bold statement from an armchair UX designer. They obviously have reasoning and supporting data, maybe you're in the minority of users who've found that useful?

Thanks for the feedback! In this iteration, we think recovering more space helps users focus on content, and allows them to see more content at once. Definitely we recognize the tradeoff of additional clicks and discoverability as a result.

We are definitely focused on usability, and navigation in general. We don't claim to know all the right answers all the time. So we are iterating with each release, and working hard doing user research as well to inform our decisions. You can see some of our recent work regarding nav here: https://gitlab.com/gitlab-org/ux-research/issues/3. Thanks.

The application I'm working on, I went with a 3-state navigation... null (default), true (open) or false (closed) ... at large screen sizes null is a soft open, smaller soft closed... toggling goes between the respective hard state and the null/default state. At sm-medium, it's an overlay, at phone/xs it takes over the screen.

I find that this is more intuative to use than a hard on/off only.

I agree with the parent about the sidebar. I already disliked the change to make it hidden by default with the pin option since it was a bit inconsistent for me, but it at least gave the option for best of both worlds.

Ideally this should be an option. I get that 'modern UX' is all about more screen space and whatnot, but I'm not a fan of that trend personally. It seems that all that's been gained from that change is more empty space at the side of pages. Personally, I'm the type that would rather have more information and convenience on the page than extra space.

Would it be that hard to add an option to enable the side bar if people want it? That's what I like about GitLab, that it's very configurable.

The ongoing discussion regarding the sidebar/navigation is here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835. Thanks again for the feedback.

What's sad is that this isn't the first time GitLab UX/UI peeps have tried to remove the sidebar.

9 months ago we went through a very similar version of this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18542

Can we just all agree to keep the damn sidebar available - if UX wants to remove it, fine, as long as users have the ability to easily permanently pin it back open if they wish to do so.

By now GitLab UX should realize that enough developers find great utility in that sidebar.

Perhaps the 'sad'/'damn sidebar'/'should realize' passive-aggressive entitlement doesn't help?

Yes, I'm sure Gitlab's engineers make technical decisions based on this guy's tone in Hacker News comments.

Maybe they just feel bad when they are going to sleep.

His tone almost guarantees his complaint won't be take seriously.

Also, just being nice is a generally good principle.

I sincerely apologize if the tone in my post offends anyone - I let my frustration with this issue get the better of me while writing my comment.

However, I do stand behind the main points of what I wrote:

1. It's disappointing and frustrating to see what is almost the same issue coming up only 9 months later (please look at the link I shared above), where now I'm seeing all the same arguments in favor and against the side bar in these comments as well as in the new related issue thread. We are going through almost the same exercise again.

2. On removing the sidebar - allowing the sidebar to appear and be pinned would be a more inclusive UI/UX choice. Please allow us to pin it again.

I will also add that over the last 1.5 years we've been using GitLab EE the GitLab team has been awesome. I'm continually amazed at how quickly many feature requests become part of GitLab.

Yeah I miss the sidebar too, it annoyed me and our devs when the pinning was broken and then when there were less items in it.

It felt like without the side bar there is wasted screen realestate that could have project related options or navigation in the side bar.

As resolutions and screens get larger I'm a strong believer that as long as you don't over complicate or make the interface too busy, you shouldn't waste ⅔ of a web site with white space.

Regardless, very happy with 9.0 otherwise, another fantastic release from the team and contributors.

Reply on news.ycombinator.com