A Unique Performance Optimization for a 3D Geometry Language

https://news.ycombinator.com/rss Hits: 2
Summary

For the past several months, I’ve been working on a programming language called Geoscript. It’s specialized for generating and manipulating 3D geometry for use in a Shadertoy-inspired web app called Geotoy. Geoscript uses a pretty simple tree-walking interpreter for its execution. That being said, I’ve put in a decent amount of effort optimizing it for runtime speed as well as building up an optimization pipeline for the language itself. While working on this, I discovered a pretty neat optimization opportunity that's uniquely suited to this use case. But first, let me give a little background on Geoscript’s optimization pipeline to give some history and context. (or just skip to the “Cross-Run Expr Cache Persistence” section below if you want) Geoscript Optimization Pipeline⌗ The first optimization I added for geoscript was basic constant folding. Nothing special or unique so far; just the usual approach of finding things like { op: Add, lhs: Literal(1), rhs: Literal(1) } in the AST and replacing it with Literal(2). I got the initial version working pretty quickly and started extending it to support more operations and data types. As I continued, I quickly came to realize something: Almost everything in a typical Geoscript program is constant and doesn't depend on any external or dynamic input Unlike programs from other languages, Geoscript doesn’t accept user input, perform DB calls, or interact with any external system at all. There are some small exceptions to this like PRNG calls and side effects to render meshes or print debug messages. But since the RNG is seeded, a Geoscript program is really just a pure function with zero arguments; it produces the exact same output every time it’s run. Because of this fact, once I made the constant folding smart enough, it turned out that most or even all of the program would end up getting ran during the “optimization” process. This even applies to closures, as long as the variables they capture from the outer scope are t...

First seen: 2026-01-15 22:18

Last seen: 2026-01-15 23:18