CGO是非常慢的。因爲CGO其實一個橋接器，通過自動生成代碼，CGO在保留了C/C++運行時的情況下，搭建了一個橋來溝通C/C++世界和Go的世界。這就意味著，兼容性很好，但是對C的函數的調用，必須先把當前的goroutine掛起，並切換執行棧到當前的線程M的主棧（大小2MB）。如果不做這個操作，那麽只能在goroutine的棧上執行C函數調用，可是，goroutine的棧一般都很小，很容易就導致了棧溢出了。
調用C函數的時候，必須切換當前的棧爲線程的主棧，這帶來了兩個比較嚴重的問題：
線程的棧在Go運行時是比較少的，受到P/M數量的限制，一般可以簡單的理解成受到GOMAXPROCS限制；
由於需要同時保留C/C++的運行時，CGO需要在兩個運行時和兩個ABI（抽象二進制接口）之間做翻譯和協調。這就帶來了很大的開銷。
minio項目的一個副産品是 c2goasm 項目，這個項目也被 go-cv-simd 項目使用獲得了很好的效果。
c2goasm 的角色是一個 滙編語言轉換器，輸入是 clang輸出的amd64滙編，輸出是go滙編。而clang的輸入是C/C++語言。限制是不能有RTTI和異常。也就是說不能有C/C++運行時提供的高級功能。
c2goasm輸出的go滙編，交給go的工具鏈可以直接生成go的可執行代碼。
c2goasm和CGO比，最大的改進就是：
不再有C/C++運行時，也就沒了在兩者之間不停轉換的邏輯開銷；
不需要切換到線程的主棧來執行函數，因爲c2goasm生成的是純正的go函數，不需要線程的主棧就可以執行；
由此就極大的改進了性能，代價是兼容性和可移植性損失了。
