Also while testing gccgo creates a yay binary of size 1.5MB (probably because it links dynamically to alpm.so) go creates a yay binary of size 4.7MB gccgo has an install size of 149MB and download size of 22MB go has an install size of 330MB and download size of 67MB
I was also curious what led to such a difference. My suspicion was the static
linking of the go runtime was done by default in
go but not
First I created a binary from the same release
yay-gcc for the gccgo and
yay-go for the go version.
Both were built using
go build (using the respective compiler) so they were
not stripped (
yay-gcc had 2.4MB and
yay-go had 7.3MB)
ldd to check the direct and indirect libs needed, was
ldd yay-go displayed 31 lines and
ldd yay-gcc displayed
34 lines. In both cases
/usr/lib/alpm.so.10 was linked.
pkgfile -s on each file these packages belong to core/gcc-libs and core/glibc
readelf -d binary | grep NEEDED will return our direct dependencies
So we can estimate the size of the go runtime in
yay to be
3.2MB when the
binaries are stripped and
4.9MB when not stripped.
As a comparison I decided to analyze using radare2 the amount of function
symbols present using:
radare2 and exporting symbols grepping
Roughly a 4440 FUNC symbol difference is noticeable between the 2.
I would have liked to do proper benchmarking of the 2 binaries, unfortunately
it was a bit too much work to set up a reproducible environment to run
yay -Syu a 100 times, even without taking into account networking.
On a system without any updates available:
After reproducing the same test a couple of times
yay-go (as predicted) has a
better performance than
go compiler is more optimized than
gcc-go according to some sources online, and accessing linked libraries is
So to conclude:
- The 4.9MB difference is due to the static linking of the go runtime in
yay-gois still faster than
yay-gccby about a
100%in mediocrely done benchmarking.