top of page

Performance Comparison of RUNC vs CRUN Container Runtimes

What is your favorite container runtime? During one of our recent projects, we discovered that container runtimes can have a massive response time and infrastructure impact. My lesson learned is to research if a better option is available instead of taking suggested container runtimes for granted.

One of our customers migrated RHEL7.9 to RHEL8.8, and as part of this upgrade, they moved to Podman and RUNC as container runtime. The performance team was not involved in this decision. Our deep tracing solutions were not working for the new technology stack, so we had to investigate this problem. As a result of our investigation, we detected that tracing of RUNC is not supported, but the similar container runtime CRUN comes with tracing support.

The most significant difference between RUNC and CRUN is their programming language. While RUNC is implemented in GO, the C programming language implements the CRUN container runtime. GO is a popular programming language with a higher memory footprint and is not so close to the Linux kernel as C.

Performance comparison CRUN vs RUNC

According to RedHat, there is a dramatic performance benefit when using CRUN. Their benchmark tests indicated that

  1. CRUN is twice as fast as RUNC

  2. CRUN consumes 50 times less memory

  3. CRUN can run with 1 PID

  4. RUNC can't be limited to 1 PID

Recommended readings

Blog post by ReadHat about CRUN

More insights about container runtimes

I think CRUN is an excellent alternative to RUNC because of crucial performance benefits and a lower infrastructure footprint. Also, RedHat suggests using CRUN because of its extensibility.

Keep up the great work! Happy Performance Engineering!

Recent Posts

See All
bottom of page