openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Sciabarra <>
Subject Re: I created a variant of the go runtime that is faster at init time
Date Tue, 11 Dec 2018 15:37:56 GMT
Sorry not sure what you mean. Do you suggest I apply the change to use
gccgo in the official runtime, even if it is stuck at go 1.10 (the
latest is go 1.11) or I drop the idea of providing another runtime that
is faster to initialize? Would not be better to release both a gccgo
1.10 and a golang 1.11 instead so I leave the choice to users? The first
produces smaller binaries but it is a bit slower and it is stuck to go
1.10, the second is faster but it is slower to initialize because the
executable is bigger.--
  Michele Sciabarra

----- Original message -----
From: David P Grove <>
Subject: Re: I created a variant of the go runtime that is faster at init timeDate: Tue, 11
Dec 2018 10:17:51 -0500

Michele Sciabarra <> wrote on 12/11/2018
07:23:14 AM:>
> Then I created a variant of the go runtime, using GccGo.  GccGo is a
> Go compiler, updated to Go version 1.10, that compiles using the Gcc
> compiler infrastructure. As a result, it produces dynamically linked
> executables that are smaller than the binaries produced by the
> standard Go compiler.
> ...
> GccGo is a bit slower than Go (but it is still the second faster
> runtime) but it is now the faster at init time because the
> executable is around 50k (and zipped it is only 17k).
> I am unsure if replace GccGo in the official runtime or provide
> both. The fact that the executable is small so it leads to faster
> init time I think it is important, but the  GccGo compiler it is a
> bit behind in term of language support.

My advice is to stick with the official runtime.  I think that is betterfor end users.


  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message