3 ms·

Hey there! Jacob, Frontend leads here. At GitLab we've put together a team of 5 Frontend Engineers (including myself) to focus solely on performance and stabili

Hey there! Jacob, Frontend leads here. At GitLab we've put together a team of 5 Frontend Engineers (including myself) to focus solely on performance and stability issues. We are focusing on reducing the size of our JS and CSS. We are currently focusing on splitting our one giant JS file into many smaller JS files. Here's our current issue for code splitting the JS. https://gitlab.com/gitlab-org/gitlab-ce/issues/41341 https://gitlab.com/gitlab-org/gitlab-ce/issues/41341 Here is a link to our current CSS Refactor plan which will reduce the size of our CSS significantly and reduce render times. https://gitlab.com/gitlab-org/gitlab-ce/issues/42325 https://gitlab.com/gitlab-org/gitlab-ce/issues/42325. We've got a lot in the pipeline. In the process we won't be shipping any new features, unless you call blazing speed a feature.

kingosticks 9y ago
What real-world speedup will you see? There's no data in that issue to support the idea that this is worth doing. Surely someone hacked up a split version and ran some benchmarks, right? Maybe you could include that data somewhere as the closest thing to that I can find is: > Benefits: We will have files separated. It’s going to be better.
- jakecodes 9y ago
  I'll add our benchmarks into that issue shortly. Our biggest slowdowns are parsing, layouts, and memory. Without this splitting every file is imported, functions are instantiated but not used. With our new method only files needed are bundled and most of the dispatcher.js file is removed. Removing error prone string matching from switch statements to having it automatically done by webpack. The plan is: 1. Split up the files. 2. Get rid of the as much of the dispatcher.js as we can and have web pack do the routing dynamically. That would eliminate most of 1 large confusing file (dispatcher.js). JS is still cached for the pages you visit but it isn't 1.5mb of JS it would be ~20kb of JS.
mwj 9y ago
Jacob that stuff really has no effect on the stability of the CI system and private runners, which is the real problem.
- ayufan 9y ago
  Could you point to problems and ideally issues that you are facing? Kamil, GitLab CI/CD Lead
  - theptip 9y ago
    A few that come to mind for me: Docker socket timeouts have been floating around for a long time with no resolution: https://gitlab.com/gitlab-org/gitlab-runner/issues/2408 https://gitlab.com/gitlab-org/gitlab-runner/issues/2408 Intermittent HTTP auth errors causing build failures: https://gitlab.com/gitlab-org/gitlab-ce/issues/30670 https://gitlab.com/gitlab-org/gitlab-ce/issues/30670 More generally, tuning the runner's polling interval to minimize latency is also tricky, especially with multiple independent runners, and the runner doesn't handle 429s well in my experience (getting stuck in a tight retry loop without backing off sensibly, thus continuing to exceed its request limit). Thanks for taking the time to solicit feedback.

kingosticks 9y ago

What real-world speedup will you see? There's no data in that issue to support the idea that this is worth doing. Surely someone hacked up a split version and ran some benchmarks, right? Maybe you could include that data somewhere as the closest thing to that I can find is: > Benefits: We will have files separated. It’s going to be better.

jakecodes 9y ago
I'll add our benchmarks into that issue shortly. Our biggest slowdowns are parsing, layouts, and memory. Without this splitting every file is imported, functions are instantiated but not used. With our new method only files needed are bundled and most of the dispatcher.js file is removed. Removing error prone string matching from switch statements to having it automatically done by webpack. The plan is: 1. Split up the files. 2. Get rid of the as much of the dispatcher.js as we can and have web pack do the routing dynamically. That would eliminate most of 1 large confusing file (dispatcher.js). JS is still cached for the pages you visit but it isn't 1.5mb of JS it would be ~20kb of JS.

mwj 9y ago

Jacob that stuff really has no effect on the stability of the CI system and private runners, which is the real problem.

ayufan 9y ago
Could you point to problems and ideally issues that you are facing? Kamil, GitLab CI/CD Lead
- theptip 9y ago
  A few that come to mind for me: Docker socket timeouts have been floating around for a long time with no resolution: https://gitlab.com/gitlab-org/gitlab-runner/issues/2408 https://gitlab.com/gitlab-org/gitlab-runner/issues/2408 Intermittent HTTP auth errors causing build failures: https://gitlab.com/gitlab-org/gitlab-ce/issues/30670 https://gitlab.com/gitlab-org/gitlab-ce/issues/30670 More generally, tuning the runner's polling interval to minimize latency is also tricky, especially with multiple independent runners, and the runner doesn't handle 429s well in my experience (getting stuck in a tight retry loop without backing off sensibly, thus continuing to exceed its request limit). Thanks for taking the time to solicit feedback.