]> Cypherpunks repositories - gostls13.git/commit
cmd/compile: avoid giant init functions due to many user inits
authorJosh Bleecher Snyder <josharian@gmail.com>
Mon, 24 Apr 2017 00:31:15 +0000 (17:31 -0700)
committerJosh Bleecher Snyder <josharian@gmail.com>
Mon, 1 May 2017 18:00:11 +0000 (18:00 +0000)
commitd1b544c7eb00d54d7298292c1860a965ecc93d41
tree0373d595f5aebe6dc84cb9181a2ac934c125c3e4
parentb666f2860b2735eb61fe5a03dd90c3af8eed1ec3
cmd/compile: avoid giant init functions due to many user inits

We generate code that calls each user init function one at a time.
When there are lots of user init functions,
usually due to generated code, like test/rotate* or
github.com/juju/govmomi/vim25/types,
we can end up with a giant function,
which can be slow to compile.

This CL puts in an escape valve.
When there are more than 500 functions, instead of doing:

init.0()
init.1()
// ...

we construct a static array of functions:

var fns = [...]func(){init.0, init.1, ... }

and call them in a loop.

This generates marginally bigger, marginally worse code,
so we restrict it to cases in which it might start to matter.

500 was selected as a mostly arbitrary threshold for "lots".
Each call uses two Progs, one for PCDATA and one for the call,
so at 500 calls we use ~1000 Progs.
At concurrency==8, we get a Prog cache of about
1000 Progs per worker.
So a threshold of 500 should more or less avoid
exhausting the Prog cache in most cases.

Change-Id: I276b887173ddbf65b2164ec9f9b5eb04d8c753c2
Reviewed-on: https://go-review.googlesource.com/41500
Reviewed-by: Keith Randall <khr@golang.org>
src/cmd/compile/internal/gc/init.go
src/cmd/compile/internal/gc/sinit.go