3 ms·

I'm not sure I understand how using ego ensures that it is fast. Could someone ELI5 please?

landr0id 10y ago
I guess it's because the templates don't have to ever be parsed since they're transpiled to Go code at compile-time. It's been a while since I've used Go's template packages but I thought that they're only parsed once no matter how many times you execute it (assuming reuse of the Template struct). So to me, it seems there should really be no difference from just putting the initialization of the template in an init() func.
- chewxy 10y ago
  Nothing is stopping you from doing something stupid like this though: func AtRuntime(writer io.Writer){ templ := template.Must(template.New("blah").Parse(templateText)) templ.Execute(writer, someStructhere) } Though most sane devs would put the template parsing code in init()
  - leetrout 10y ago
    This brings up another question... Couldn't you just put them in the global namespace in the package? I also don't see the need for init since this is just parsing / compiling a template one time. Maybe I'm just not a sane dev? I just put all my template and regex "must" statements as global vars in my package close to where they're used.
    - randomdata 10y ago
      Most definitely, if you want the compiled template loaded for the life of the application, at least. The documentation for template.Must says it is intended to be used exactly like that. If you were in a regular code block, you would check the error and handle it more gracefully.
mac01021 10y ago
<DISCLAIMER> I have never written a templating engine. Anything posted here by someone who has probably takes precedence over what I say here. </DISCLAIMER> A thing can only be fast relative to another thing. If ego were the only templating solution available to software developers it would be meaningless to describe it as "fast". I have never used ego and do not know how much faster it is than the alternatives (if at all). However, ego templates are compiled to go source which ends up as machine code in your program that just writes out the strings. I believe most alternative templating libraries parse your template into a data structure at run time and then need to walk that data structure every time you want to render the template in a new context. So, consider a template like "<div> <h1> {{title}} </h1> <p> {{description}} </p> </div>" Using the ego strategy the code that has to execute to render it amounts more or less to a linear series of 5 calls to a method that appends strings into a buffer. Using an interpreted-template strategy, i don't know exactly what that machine code is going to look like but it necessarily involves a lot of consulting the parsed template to see what the next step is, and maybe even a lot of lookups of strings in hash tables. Aside: In the Java world, the fastest template rendering engines probably compile a template into JVM bytecode which can then be loaded and executed in the current process, yielding what could reasonably be considered the best of both worlds.
bouk 10y ago
Ego is as fast as it gets for tenplating, as it compiles the template to Go code. It probably doesn't matter that much performance wise in this case, I would've used it either way.

I guess it's because the templates don't have to ever be parsed since they're transpiled to Go code at compile-time. It's been a while since I've used Go's template packages but I thought that they're only parsed once no matter how many times you execute it (assuming reuse of the Template struct). So to me, it seems there should really be no difference from just putting the initialization of the template in an init() func.

chewxy 10y ago
Nothing is stopping you from doing something stupid like this though: func AtRuntime(writer io.Writer){ templ := template.Must(template.New("blah").Parse(templateText)) templ.Execute(writer, someStructhere) } Though most sane devs would put the template parsing code in init()
- leetrout 10y ago
  This brings up another question... Couldn't you just put them in the global namespace in the package? I also don't see the need for init since this is just parsing / compiling a template one time. Maybe I'm just not a sane dev? I just put all my template and regex "must" statements as global vars in my package close to where they're used.
  - randomdata 10y ago
    Most definitely, if you want the compiled template loaded for the life of the application, at least. The documentation for template.Must says it is intended to be used exactly like that. If you were in a regular code block, you would check the error and handle it more gracefully.

mac01021 10y ago

<DISCLAIMER> I have never written a templating engine. Anything posted here by someone who has probably takes precedence over what I say here. </DISCLAIMER> A thing can only be fast relative to another thing. If ego were the only templating solution available to software developers it would be meaningless to describe it as "fast". I have never used ego and do not know how much faster it is than the alternatives (if at all). However, ego templates are compiled to go source which ends up as machine code in your program that just writes out the strings. I believe most alternative templating libraries parse your template into a data structure at run time and then need to walk that data structure every time you want to render the template in a new context. So, consider a template like "<div> <h1> {{title}} </h1> <p> {{description}} </p> </div>" Using the ego strategy the code that has to execute to render it amounts more or less to a linear series of 5 calls to a method that appends strings into a buffer. Using an interpreted-template strategy, i don't know exactly what that machine code is going to look like but it necessarily involves a lot of consulting the parsed template to see what the next step is, and maybe even a lot of lookups of strings in hash tables. Aside: In the Java world, the fastest template rendering engines probably compile a template into JVM bytecode which can then be loaded and executed in the current process, yielding what could reasonably be considered the best of both worlds.

bouk 10y ago

Ego is as fast as it gets for tenplating, as it compiles the template to Go code. It probably doesn't matter that much performance wise in this case, I would've used it either way.