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.

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.

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

Could you point to problems and ideally issues that you are facing?

Kamil, GitLab CI/CD Lead

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

Intermittent HTTP auth errors causing build failures: 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.