> CI is an overgrown shell script running your build and telling you when it fails.
Oh, I wish it were that simple...
But, I also don't know what they measured. But, I'll give you just one example. Jenkins default landing page is a disaster in terms of speed. It tries to display data on recent builds everywhere across your cluster. For even not so big clusters this can be hundreds to thousands of items to pull from individual nodes running those builds. I've managed to crash Jenkins more times than I could count by simply loading the landing page w/o a particular configuration added that prevents it from its default behavior.
CI server will have its own database, typically, managing all sorts of CI entities: jobs, artifacts, users, secretes... It could be quite big and you'd do well taking care of proper indexing etc.
CI will have its assortment of runners, which are often provisioned dynamically (think VM or Docker images that need to be deployed to runner nodes), distributing them across the cluster is also not an easy task, if you want that to work fast. Of course you also want to be able to distribute the artifacts across the cluster -- this also takes time and resources.
CI will have its own bookkeeping necessary to, essentially, do garbage collection, reporting and self-diagnostic.
In big enough clusters this stuff can have a very high latency, if you don't specifically work towards reducing that latency.
> If you want fast CI you need fast tsc, clang, rustc, etc... not a faster program that calls exec on them.
Ever heard of ccache?
But, really, this is also super-naive. To make builds fast in a distributed system that CI is you would also need to figure out how to distribute this cache, how to modularize the builds... You might have heard about how one of the most difficult things in programming is cache invalidation? -- That's only partly a joke.