How fast are dynamic pages by template served?

<p>When you serve a web page that has already been compiled and, now, executed with executeTemplate, is that served as fast as a static page served from a directory somewhere? </p> <p>This may relate to my other question in the sub about static html pages. I&#39;m not sure whether it&#39;s better and faster to create a static file and let the server serve that or let Go handle it as part of executeTemplate() and all the other web pages compiled together.</p> <hr/>**评论：**<br/><br/>jerf: <pre><p>I don&#39;t know the answer to your question, so I&#39;m not trying to dodge out of answering it. If I wanted to figure it out, I&#39;d use the <a href="http://golang.org/pkg/testing/">benchmarking tool</a>. It&#39;s fairly easy to set up.</p> <p>If you need help figuring out how to properly simulate an http rendering call, holler here and somebody will help you.</p> <p>There is one special case to note here, though. As Determination points out, Linux has special support for taking a file and stuffing it down a socket without any userspace intervention. Your benchmark probably won&#39;t trigger that code, and you&#39;d have to use an external profiler to see the &#34;real&#34; speed. Unless you&#39;re going to serve many thousands of small pages per second from static files, though, it won&#39;t matter. (Of course, if you are doing that, it may.)</p></pre>captncraig: <pre><p>The text/tamplate and html/template packages operate in two main phases:</p> <ol> <li>Compile template string into a parse tree.</li> <li>Execute template by walking parse tree.</li> </ol> <p>Step one can be performed once at startup, but step two must be run each time. Note that templates are not extremely optimized for execution performance, although they are not super bad by themselves. </p> <p>If you write {{.Foo}}, there are a number of possibilities depending on the context you give to the template. Foo could be a simple field, a method, or even a key you want to look up in a map. The library must use reflection to decide this, which takes time. It also must handle nil cases and cases where the field does not exist and so forth. All of that takes time.</p> <p>If you really want it to be fast, static code can&#39;t be beat. I have experimented with generating code from go templates. I have a semi-working prototype that only works with a subset of the template language, but it performs much better. For extremely simple templates I have seen render times in microseconds with the template package reduced to ~100ns for cleanly generated equivalent code. It is a really hard problem and I am not sure it is worth the effort, but it interests me. Having the benefit of compiled speed and strict type checking would be great. </p> <p><a href="https://github.com/sipin/gorazor" rel="nofollow">https://github.com/sipin/gorazor</a> takes a code generating approach, which lets you make straight go code from templates, but you also lose the dynamic reloadability at development time, so there is a tradeoff.</p></pre>dhdfdh: <pre><p>This is what I&#39;m wondering about. As <a href="/u/Determination" rel="nofollow">/u/Determination</a> talks about, though, static files are read off disk which could be slower than parsed templates cause they&#39;re held in memory. I&#39;m wondering about sites that have a high load with hundreds and thousands of templates, though. That would be a lot of memory but it&#39;s not something that affects what I do.</p> <p>Until his answer, I was thinking of parsing the templates but saving them to disk as static files, instead of immediately sending them out on the wire but, as I said, then you have the slowness of reading them off the disk.</p></pre>Determination: <pre><p>Static files, if you are loading the file within a request, hits the filesystem, so it&#39;s inherently limited by the filesystem I/O. LInux kernels help with this, but it&#39;s still a cost. Alternatively a technique you could use is load all the files in memory before hand. That way all the file content is in memory and you only have to hit the FS once. But, that&#39;s more complicated to manage.</p> <p>As long as you compile your templates before the request (on Server object construction, for example), compiled html.Templates are in memory and are executed on demand. Super fast. Plus, they can be dynamic if need be.</p> <p>It&#39;s all about trading time / memory upfront for less &#34;work&#34; on within in request. The less work you have to do in the request window, the better.</p> <p>But, it should simple enough to test...</p></pre>calebdoxsey: <pre><p>What kind of traffic are you expecting? In my experience dynamic templates are plenty fast and I never saw much of a need to do anything about it. (dynamic here meaning read the file off the disk, compile the template, and execute it)</p> <p>Skipping the performance question: the benefit of the dynamic template is it lets you surface errors as part of a request rather than at the command line. That can make debugging and development a little easier.</p> <p>On the other hand static HTML gives you the option of deploying to an S3 or GCS bucket (or your own nginx server). If you need server-side functionality you can then make your Go program a pure JSON API and not have to worry about templates at all.</p> <p>Whether or not that&#39;s better is hard to say - but its definitely an approach that&#39;s becoming more popular as sites become more and more Javascript heavy. </p></pre>