HI!
Some updates here, again!
Down the road, i realized my benchmarks where not so correct,
kind of erratic with sometimes huge improvements,
sometimes minor improvements.
I got this sorted out, and found the root of evil to be
`template.HTMLEscapeString`
So i worked this out, and now i m very happy to show you the latest
benchmarks,
as they really are encouraging,
$ go test -bench=. -benchmem
BenchmarkRenderWithCompiledTemplateA-4 20000000 78.9 ns/op
48 B/op 1 allocs/op
BenchmarkRenderWithJitTemplateA-4 3000000 668 ns/op
96 B/op 2 allocs/op
BenchmarkRenderWithCompiledTemplateB-4 20000000 82.4 ns/op
48 B/op 1 allocs/op
BenchmarkRenderWithJitTemplateB-4 3000000 603 ns/op
96 B/op 2 allocs/op
BenchmarkRenderWithCompiledTemplateC-4 500000 2530 ns/op
192 B/op 6 allocs/op
BenchmarkRenderWithJitTemplateC-4 50000 38245 ns/op
3641 B/op 82 allocs/op
BenchmarkRenderWithCompiledTemplateD-4 20000000 114 ns/op
48 B/op 1 allocs/op
BenchmarkRenderWithJitTemplateD-4 3000000 809 ns/op
144 B/op 3 allocs/op
// the next 2 benchmarks are particularly encouraging
// as they involve 2k html string escaping
BenchmarkRenderWithCompiledTemplateE-4 10000 103929 ns/op
160 B/op 2 allocs/op
BenchmarkRenderWithJitTemplateE-4 300 6207912 ns/op
656598 B/op 18012 allocs/op
BenchmarkRenderWithCompiledTemplateF-4 10000 111047 ns/op
160 B/op 2 allocs/op
BenchmarkRenderWithJitTemplateF-4 200 5836766 ns/op
657000 B/op 18024 allocs/op
The trick was to get ride of calls to `template.HTMLEscapeString`
See its code here
https://golang.org/src/text/template/funcs.go?s=13003:13041#L505
The problem in this function is that it trades an allocation for doubled
iteration on the string to escape.
Which makes sense for the std package as it does a lots of allocations,
but in the case of compiled templates it does not make sense as the
allocations count
is drastically reduced.
Now, one could say, right, lets just invoke `template.HTMLEscape(writer,
[]byte(string))`
instead of `template.HTMLEscapeString`.
I gone down that road too, and its not totally satisfying because it
actually creates
as many new allocations as there are calls to HTMLEscape (see the
[]byte(string) conversion).
In the end, i decided to use a buffer, it creates a static extra allocation,
at beginning of every template function, but avoid so many possible and
future
string to byte conversion.
Finally, html escaping string looks like this,
func fnaTplaTpl0(t parse.Templater, w io.Writer, indata interface { })
error {
var bw bytes.Buffer
// ...
bw.WriteString(somestringhere)
template.HTMLEscape(w, bw.Bytes())
bw.Reset()
}
Doing so the allocation count stays very low stable, and it s still
possible to reduce cpu usage.
I looked into the std packages, i could not find an obvious way to
implement that optimization,
maybe you have some ideas ?
Anyway, there s still a lot to do on this compiler!
The next steps will be
- to remove duplicated std package, i made my mind to not even try to patch
core code.
- to implement more optimizations
- to improve the end user programmatic interface
That's it!
On Saturday, January 21, 2017 at 3:58:53 PM UTC+1, mhh...@gmail.com wrote:
>
> Hi,
>
> I have been working on a package to compile go templates to regular go
> code.
> Today i can announce an early release of it.
>
> Find it here
> https://github.com/mh-cbon/template-compiler
>
> There is still have a lot to test and comment,
> and to detect some edge cases.
> But the general idea and structure exists, does work,
> and shows a way to make that happen.
>
> If you are interested to get this production ready,
> i d like very much to see your questions and PR!
>
> Being in a hurry, this announce is very short,
> I expect a more detailed announce later.
>
> This said, i d like to ask the go team if the template package
> could have a new structure to register a func as a template,
> see 1
> <https://github.com/mh-cbon/template-compiler/blob/master/std/text/template/compiled.go>,
>
> 2
> <https://github.com/mh-cbon/template-compiler/blob/master/std/text/template/parse/compiled.go>
>
> and 3
> <https://github.com/mh-cbon/template-compiler/blob/master/std/text/template/exec.go#L247>
>
> Finally, i want to take chance of this message to wish
> to the golang, core team, contributors, users
> an happy new year and all the best for 2017!
>
> Happy coding!
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
