GuestNo new alerts

Why are the templates so fast?

- Articles1491
You've probably been hearing a fair bit about the template system, like transpiled versus interpreted and what-not, but what does it all really mean? Well, in short, the standard library by default will send templates through a dance through countless nested functions, layers of indirection created by reflection, etc. which lets us be fast compared to PHP, but is still really quite slow.

But how can that be, is Go not extremely fast? One might ask. Well no, it's all in how you use the tools, if I were to write Gosora as if performance didn't matter, then we would be slower than a brick right now.

The biggest thing to remember when thinking about performance, is not so much how fast things are. But how fast will be after someone installs 50 plugins, does all sorts of fancy templating, or other things which bring things slowing to a crawl.

My solution to the wasted cycles and extremely slow render times was simple yet not simple. I took the AST generated by the parser for the stdlib and just turned that into Go instead of running it on the spot. Go is an extremely fast language, even with the compromises to make working in it pleasant and benchmarks immediately showed it running 20 times faster.

That is significant. That is so significant, that it cut the overall route time at the time in half.

With those results, I was ready for a mass-conversion, but there was one problem.

Going too far would bloat the code size up beyond recognition which could result in my optimisations horribly backfiring, hence I limited it to areas users frequented such as the topic page, topic list, etc. and just about every spot a guest could hit to help cope with aggressive crawlers and bots.

As for the control panel, it was left largely untouched, as-well as the account manager. I really didn't to optimise these for huge waves of requests considering how rarely they were touched. And for the large part, this worked fairly well. In fact, if you listen to the benchmarks, Gosora can outcompete Nginx serving static files by a large margin.

But of course, I don't want to stop there, while the areas with less optimisations are small gains, I have plans in mind to expand coverage to the entire account manager at once, and without as big a size penalty, which should about cover the entire surface area available to ordinary users.

These optimisations will also have the pleasant side effect of making it easier for me to render templates on the client-side to help cut out sending large HTML files entirely in some situations which will be great for users living far away from the physical servers (including me, ironically enough).

And okay, so now that I have given you a quick primer, let's look at what the code actually looks like:


Just an ordinary Go file. No magic or fairy dust. Just a bunch of writes much like the standard library.

And... That's it. It's a very simple system, or at-least it was, haha. It's grown a fair bit and there's a bit of code for loading phrases, registering handlers for Gosora to be able to address the template (earlier builds called the function directly o.o), etc. but it's still fairly simple.

The precise implementation admittedly, has taken a fair bit of work at times to get it to work (especially debugging it at times), but it was a small price to pay for quick templates which happen to be a standard which every Go Programmer knows about.

As for the amount of code needed to orchestrate all of this? It really isn't anything huge at all, at-least compared to how much you might expect. Around two thousand lines of code. I've seen task schedulers for some sites which were several times longer than that.

If you have any questions or feedback, feel free to say so below.