funcs: sprig function setup is computationally costly

[jrasell]

I have done some recent work on the Nomad team to understand its template runner profile. Nomad utilizes consul-template as a library to provide the job specification template block functionality.

The test I performed to generate the flame graph attached included taking a 120s profile of a Nomad client which was running allocations utilizing the nomadVar template function.

Sprig function setup code reference:

consul-template/template/template.go

Lines 440 to 443 in faf8404

	for k, v := range sprig.TxtFuncMap() {
	target := "sprig_" + k
	r[target] = v
	}

The code is costly in two ways, particularly considering the sprig.TxtFuncMap function returns a map with 210 entries:

• the string concatenation used to generated the map key for the function name which is unavoidable no matter where the setup occurs
• the growth of the map which the sprig functions are entered into, which is initialised here and could potentially be improved

Proposal

Move the template function setup functionality into a more efficient process to improve the overhead seen on all template execute calls.

It could also be possible to have a configuration option to disable to use of sprig functions, however, library implementors such as Nomad would need to plumb this through. This would be time consuming for both us as engineers but also Nomad users, as they would need to update all their configurations to make use of this.

To further demonstrate the overhead, I ran a quick experiment using the process described above with Nomad built using a hacked consul-template version which had removed the sprig setup code:

[thevilledev]

I have a proposal to improve this in #2052. The string concatenation cost is then incurred only once when the package loads, not on every template execution.