Livecoding EEx template improvements (twitch livestream)

Thanks @tmbb for the compliments and all of the ideas so far. The changes I did in EEx are indeed a small subset of what we would find in Vampyre or LiveView.

Today I live streamed the implementation of LiveEEx: https://github.com/josevalim/live_eex

The engine does two main things:

• It keeps static and dynamic parts apart
• It tracks when each assign is used and it does not compute such parts if the assigns did not change

The analyze code is relatively straight-forward and all it does is to track whenever an assign is used. However, in order to not change the semantics of the code, we give up the analyze if it sees any variable or lexical command.

This is a different set of optimization compared to Vampyre. Vampyre is about increasing the amount of static parts. Currently I am working on reducing when the dynamic parts are sent. Both are very useful.

Tomorrow we should work on template fingerprinting so we can handle nesting and we will likely work on the Phoenix integration. The whole thing should be less than 400LOC, which is really neat, and this would not be possible if it was not for your initial suggestions on how to structure compiled code!

Yes, it’s possible to have both groups of optimizations at the same time. I believe that whatever optimizations you’re applying (I haven’t been able to see the video yet) can be made even more efficient on Vampyre’s fully macroexpanded code.

I just went ahead and implemented fingerprinting now. Here are the docs on why we need it.

I have also improved the analysis code to be more optimal and it is around 110LOC. There is a big comment section explaining how it all works: https://github.com/josevalim/live_eex/blob/3b4a8b727d577d8885f8816ef9adb3d244cb6acf/lib/engine.ex#L399-L511

With the analysis improvements, everything is on 440 LOC, slightly more than I expected but also doing more than I expected, which is quite good for everything it does. The test suite is also really good, so I recommend checking that for any questions.

Very interesting. It’s amazing how you can do all of this with so little code (as I said, my version does some extra things, but still, the conciseness in your code is impressive). There is something I don’t understand. You define the fingerprint like this:

fingerprint =
  binaries
  |> :erlang.term_to_binary()
  |> :erlang.md5()

Why not something like

fingerprint = state |> :erlang.term_to_binary() |> :erlang.md5()

?

I don’t understand why you single out the binaries instead of evaluating the md5 of the whole struct, which is “more unique” and also independent of the dynamic parts. After all, the state depends on the quoted expressions that represent the dynamic parts but not on the runtime values of the dynamic parts.

I think you’re leaving out some “uniqueness” for reasons I don’t understand, and I’d like to understand why.

EDIT: a quoted expression can always be converted into a binary using :erlang.term_to_binary/1, right?

That’s because if two templates have the same static parts but different dynamic ones, they are the same for client caching purposes. Take this template:

<p><%= @foo %></p>

and

<p><%= some_fun(@foobar) %></p>

The static parts are precisely the same and if the client already has the static parts cached, we don’t need to send them again, it just needs to send the dynamic bits to be inserted.

EDIT: although I have to confess the odds of this happening are quite low. Although I would say it is the correct semantic choice to do.

@josevalim, it looks like you’re planning on sending a map of the form %{index => new_string}. I was thinking of using the fact that dynamic parts alternate with static parts to only send an array, which is more compact than a map…

But I guess sending a map is more flexible because it allows you to only send the prts that have changed, right? I thought it sending null for an array element that hadn’t changed, but your possibility is conceptually simpler.

It’s possible that both of our approaches demand different transport protocols.

In LiveEEx you try to minimize the number of segments you transmit, which means the list of segments will be sparse. A JSON map seems like a better choice in that case.

In Vampyre, I make no attempt to minimize the number of segments, but the I try to minimize the total amount of data, which results in many short segments. In this case, the overhead of encoding the map indices might be significant. However, I think the map idea is probably the best one, even for Vampyre.

If you have a lot of segments, then it is even more reason to use a map, because it is unlikely that all of them are changing at the same time and you don’t have want to have large lists with nulls. Also, when we adopt a custom serializer, we can probably reduce the representation of the map considerably.

Also keep in mind that we don’t try to reduce the number of segments, we will have as many segments as user’s <%= ... %>. But since Vampyre is able to inline stuff, then you naturally have more segments. So we are agreeing, just saying there isn’t an active attempt to reduce them.

I have also added support to for-comprehensions to live_eex, which drastically reduces the amount of data sent in for comprehensions, even on regular rendering. Take for example Phoenix’s scaffolded HTML page for index:

<%= for user <- @users do %>
  <tr>
    <td><%= field1 %></td>
    <td><%= field2 %></td>
    <td><%= field3 %></td>
    <td><%= field4 %></td>
    <td><%= link "Show", to: ... %></td>
    <td><%= link "Edit", to: ... %></td>
    <td><%= link "Delete", to: ... %></td>
  </tr>
<% end %>

If you have 10 users, the example above would send the static parts (the tr and td) for each user. Now we just send the static parts once regardless of the number of users. And if you are adding or removing users, the static parts are never sent again. This reduces the data of each initial render and of each update alike.

After all of those optimizations, the rainbow example that Chris showed at ElixirConf is now sending only 1% of the data that it did at the time. Back then it already rendered at 60 fps and reducing the amount of data sent is definitely going to make it more resilient to latency.

Currently I make no efforts to send only what’s changed. I just send everything, and that’s why I think an array might be better for me.

Exactly

Oh, now I see what you mean by “an attempt to reduce the amount of data sent”.