After the Refactor: A Path to Faster Rendering with Liquid-C

Summary

Liquid-C is an extension to the Liquid gem that parses, tokenizes, and renders templates, but some Liquid features, including If and For tags, still render in Liquid rather than Liquid-C. The work explains how Liquid-C compiles templates into bytecode for a customer VM and addresses the difficulty of moving instruction and constant pointers when control flow requires forward or backward jumps. It refactors instructions to store each constant’s index in the constants array, using a hash table to avoid duplicate constants and remove the constant pointer. The change reduced one example constants array from 157 objects to 104, but did not drastically improve theme rendering speed; it slightly increased memory usage and parsing time while preparing for GOTO or JMP operations and later If and For support.

Context

Liquid-C was introduced to accelerate Liquid parsing, but not every Liquid feature had been ported to it. The If and For tags were still rendered in Liquid, and implementing them required bytecode control flow that could move the instruction pointer forward or backward without the existing constant-pointer calculations.

Approach / What changed

The refactor removed the VM’s constant pointer by storing each constant’s index directly in bytecode instructions. A hash table records constant indexes and prevents duplicate values in the constants array, enabling future GOTO or JMP operations for compiled control flow.

Takeaways

• The refactor reduced the constants array for performance/tests/dropify/cart.liquid from 157 objects to 104 objects.
• Liquid-C’s new hash table and instruction structure slightly increased memory usage and Liquid template parsing time.
• The change did not drastically improve Shopify theme rendering speed, but it was intended to enable faster If and For tag rendering through future jump operations.

Related reading