Python in Excel is genuinely useful. If you already know Python and you need to do something pandas is good at, it is a reasonable choice. But there is a cost that is not always obvious upfront, and it shows up quickly at scale.
Why Python in Excel is slow
Python in Excel does not run inside Excel. It runs in a separate Python environment, effectively a service, and communicates with Excel over a bridge. Every time your worksheet calls a Python function:
- The arguments get serialized out of Excel’s internal format
- They travel across a process boundary
- Python executes the function
- The result gets serialized back
- Excel receives and applies it
For a single call on a small range, that is imperceptible. For a hundred calls on a large worksheet, or for functions that recalculate frequently, that overhead compounds quickly. Users notice. Workbooks that should feel instant start to feel sluggish.
Office Add-ins have the same problem. Different language, same bridge, same overhead.
How XLL functions are different
XLL add-ins run inside the Excel process. There is no bridge, no serialization, no inter-process hop. Excel calls your function the same way it calls SUM: directly, in-process, handing it a pointer to the data.
On top of that, Excel can call thread-safe XLL functions in parallel during recalculation. If your worksheet has 500 cells calling your custom function and you have an 8-core machine, Excel can dispatch those calls across 8 threads simultaneously. Nothing else in the Excel extension ecosystem can do this.
The performance difference is not marginal. For computation-heavy or data-heavy custom functions, it is the difference between a workbook that feels like a spreadsheet and one that feels like a web app from 2009.
The problem with XLLs
Until recently, building an XLL meant writing C or C++, using a low-level SDK that predates Windows XP, managing memory manually, and wading through documentation that is sparse at best. Microsoft’s own docs note that the investment required makes XLLs “impractical for most users.”
That is why most teams reach for Python or JavaScript instead. Not because those are faster, but because they are accessible.
xllify: XLL performance, without the C++
xllify wraps the XLL runtime so you write functions in Luau, a clean scripting language, and get a native XLL as output. Multi-threaded recalculation is on by default. The result is a single .xll file that drops into Excel with no dependencies.
If your custom functions are slow, the answer is not to optimise the Python. The answer is to stop running Python out-of-process and start running compiled code inside Excel instead. That is what xllify does.