Haskell Snap Framework templating 3000x faster with new release

http://snapframework.com/blog/2012/12/9/heist-0.10-released

by LukeHoersten • 14 years ago

114 32 14 years ago

Independent of Haskell, Heist is one of my favorite HTML/XML template engines so it's great to see such huge advancements.

riffraff2• 14 years ago

could you expand on why is it that you favor it?

I ask because I like the idea of a stateless xmlish template language, but I wonder what this offers over the zillion existing solutions.

"Separates view and business logic" and "enables DRY design" are valuable goals, but most template languages have them.

papsosouid3• 14 years ago

I'm not him, but personally I like it because html is actually a pretty good language for markup. I find any custom syntax to be worse than just html, and you lose the ability to use standard html tools, syntax highlighting, etc.

And as much as it may be possible to separate logic from presentation in a typical PHP/ASP/JSP style template, I've never actually seen it done. When something is made awkward, people tend to choose the more convenient approach, so you see an unfortunate amount of nested loops and conditionals in most templates. Being able to have designers write templates by simply telling them "anywhere you want dynamic content, just make up an appropriately named tag for it and pretend it is part of html" is really nice.

LukeHoersten3• 14 years ago

Good question. A few reason:

1. Heist allows you to define your own HTML/XML tags in the host language (Haskell in this case). This means you're only dealing with (an extended) XML document when doing layout and design so all the normal XML tools still work.

2. Some popular template engines try to separate logic and design but end up letting you cheat a little. Any time you want/have to cheat and put logic in the template, it really was a shortcoming of the template engine. In Heist, you can't cheat but you never want to.

3. The reason #1 and #2 work is because Heist's "recursively applied splices" is just the right abstraction. My HTML templates end up looking just as pretty as well factored Haskell code. Heist makes the perfectionist in me happy.

In short, I would say you're right here: '"Separates view and business logic" and "enables DRY design" are valuable goals, but most template languages have them.' But just because most template languages have these goals doesn't mean they've achieved their goals. Heist, in my experience and opinion, does achieve these goals.

papsosouid3• 14 years ago

But this doesn't apply to splices that need data at runtime, like say pulled from a database right? Isn't that typically going to be 95% of your splices? The performance increase seems a bit overstated if it only applies to splices that are just simple substitutions.

mightybyte7• 14 years ago

This might apply to 95% of splices, but not 95% of your template. This particular benchmark does show the best case, but the typical case of a few dynamic splices will not affect things much because the page is still getting converted into a concatenative style and a ton of the splice processing of things like <bind>, <apply>, etc is happening at load time.

lrem2• 14 years ago

I wanted to ask how is that even possible, then read:

> However, we realized that a lot of the transformations could be done at load time and preprocessed to an intermediate representation.

Lazy computation has its disadvantages. Still, impressive gain.

mightybyte7• 14 years ago

Thanks. I agree that it does seem too good to be true. I was also quite surprised when I saw how much of a difference it was the first time I ran the benchmarks. The great thing is that the bigger your page is, the bigger the improvement will likely be.

icarus1272• 14 years ago

> Lazy computation has its disadvantages. Still, impressive gain.

After reading the article I don't see anything about lazy evaluation. What am I missing?

mcherm• 14 years ago

I don't think you ARE missing anything. From my reading, the gains are obtained by pre-computing the string concatenation a single time (rather than while rendering) for all cases in which it can be.

It's similar to moving something from runtime to compiletime (although those distinctions don't quite apply).

dons2• 14 years ago

This isn't about deferring evaluation within a phase, its about compilation over interpretation, and the phase distinction.

primigenus• 14 years ago

I find it interesting that Heist looks to be inspired by or based on XSLT, yet XSLT is not mentioned anywhere in the documentation. Is it just a happy coincidence?

mightybyte7• 14 years ago

My inspiration for Heist came from Lift's template system. That and FBML. Heist is essentially a generalized system for building domain specific markup languages.

jlouis2• 14 years ago

5 microsecs translates to 5000 nanos. Assuming an average CPI of 0.5 we have 10000 instructions to render the template. Or 30-50 main memory fetches. This isn't too shabby.

But the numbers before the improvement. Ouch. Those were bad.

Peaker2• 14 years ago

I'm not sure measuring the number of CPU instructions makes much sense anymore.

In my experience micro-optimizing code, the majority of time is spent waiting for memory (bandwidth waits or even worse: latency costs).

jlouis2• 14 years ago

Precisely. This is why I mentioned the 30-50 mems. A typical main memory fetch is somewhere in the 100-200ns range on modern hardware. I tend to measure the effectiveness of an algorithm based on, roughly, how it accesses memory.

Caches play a role as well, of course. L1 is around 1ns sometimes even less. if you hit L2 it is in the vicinity of 5-10ns. It easily translates to some 30-40 insns on modern hardware.

It also tells you that hunting for faster execution by compressing instructions down is not going to cut you that much extra speed nowadays. The key to fast programs is data representation. Good data representation.

diggan• 14 years ago

"Built for speed from the bottom up. Check out some benchmarks." from the frontpage of snapframework.com

"When we originally wrote Heist, speed was not our goal." from the link submitted here

Feel like a contradiction, couldn't they just say that it turned out fast enough on the first try?

dbpatterson• 14 years ago

I think that comment is referring to the framework / server, which is quite fast. Heist is a templating system authored by the same people that was not intended to be fast (though now it is). It is somewhat confusing, but I don't think the work they did on the framework/server (which is totally separate from Heist) should be discounted as "fast enough on the first try."

mightybyte7• 14 years ago

Correct. We always marketed Heist as a more experimental part of the framework as a whole. The server and associated API was initially our primary focus.

andrewcooke• 14 years ago

so why did the api have to change? couldn't the compilation be done on first use? is the api change simply a change of the encapsulating monad (guessing wildly)?

not trying to bash haskell, but i think there's an interesting q about how well it (or any other language) can hide changing implementation details (particularly major ones like a compilation phase) behind an unchanging api.

or maybe that would have been possible, but the api changed for other reasons (the general cleanup)?

really interesting article btw. would have loved more detail... an explanation of introducing compilation in haskell with example would be pretty cool (pretty sure either pg or norvig has written one - with lisp - that i vaguely remember reading years ago).

mightybyte7• 14 years ago

The changes were significant because Heist isn't just an API. It's an inversion of control where you provide routines that get run for various parts of your DOM. They used to be functions that took a node and returned a list of nodes. In order to do the optimizations that we wanted to do we had to change the type signature of the callbacks that the users write to something that took a node and returned a special data structure.

We actually did preserve the old API, so you can actually migrate without making significant changes to your code. Most of those changes are because of the general cleanup. So maybe my statement about big breaking changes was misleading. They're big breaking changes IF you want the performance increase. Otherwise things still work the way they did before. In fact, the process of implementing this refactoring impressed upon me that the old paradigm was even more important that I initially realized.

If you're interested in more detail, check out the rest of the docs linked at the end. They describe the concepts in more detail with a focus on how to use them. In January I will also be giving a presentation to the New York Haskell Users Group (http://www.meetup.com/NY-Haskell/) about some of the things I learned while implementing this new approach and merging it back into the original Heist code base.

Haskell Snap Framework templating 3000x faster with new release

Related Stories