How much faster is an XLL add-in than a VBA macro?

There is no single number, and any product quoting one is quoting it for a workload that is not yours. The ratio depends on how much of your macro's time is spent calculating versus talking to Excel. Numeric loops, array work, string processing and sorting stand to gain the most. A loop that touches cells one at a time gains close to nothing until the loop is restructured to read and write in one go.

Will converting my VBA to .NET make my workbook faster?

It speeds up the parts that were slow because VBA is interpreted. It does not speed up Excel's own recalculation, disk and network access, or cell-by-cell reads and writes. To find out which kind your macro is, time it as it runs today, then time it again with the cell reads and writes replaced by fixed values. If that second run is barely faster, Excel is your bottleneck and compiling will not change much.

Is VB.NET faster than VBA?

Q: Is VB.NET faster than VBA?

For work that happens inside your own code, yes, and often by a wide margin: VBA is interpreted statement by statement, while VB.NET is compiled to IL and turned into machine code by the .NET JIT. For work that happens inside Excel, such as reading and writing cells one at a time, the two are close, because Excel is doing the slow part in both cases.

Published: 2026-10-18 · Last reviewed: 2026-10-18 · By Noam Brand, founder, Excel Armor

Short answer: it depends on what your macro spends its time doing. Compiled VB.NET removes the cost of interpreting VBA one statement at a time, so calculation that happens in memory gets much faster. It does not remove the cost of talking to Excel. A macro that reads and writes cells one at a time is limited by Excel, and compiling it on its own changes very little.

Why VBA is slower than compiled code

VBA does not run as machine code. It is compiled to p-code and interpreted at runtime by the VBA engine inside Office, and every statement carries the interpreter's overhead: decode the instruction, resolve the variable, check the type, dispatch. Most VBA variables are Variants, so the type check happens again and again while the program runs.

VB.NET compiles to .NET IL, and the JIT compiler turns the hot parts into machine code with the types already resolved. The per-statement overhead that VBA pays on every pass is gone. That overhead is small on its own. Multiply it by ten million iterations and it becomes the entire runtime.

Here is the same loop in both languages:

' VBA
For i = 1 To n
    result = result + Sqr(i) * 1.371
Next i

' VB.NET
For i As Integer = 1 To n
    result += Math.Sqrt(i) * 1.371
Next

Same input, same arithmetic, same answer. The second one runs as compiled machine code. This is the case where converting to .NET pays off most clearly, because the loop never leaves the code to ask Excel for anything.

Where the bottleneck actually sits

The reason there is no single speed multiplier is that a macro can be built in three quite different shapes, and only one of them is limited by the language.

1. VBA doing the work

Excel  →  VBA  →  calculate  →  Excel

The calculation runs in the interpreter. This is the shape that compiling helps.

2. Compiled code that still talks to Excel constantly

Excel  →  XLL  →  Excel  →  XLL  →  Excel  →  XLL  →  Excel
                     ... thousands of times

This is the disappointing one, and it catches people out. The code is compiled, the arithmetic is fast, and the macro is barely quicker than before, because the round trips into Excel never went away. If a loop touches 20,000 cells, it makes 20,000 crossings into Excel whether the caller is VBA or a compiled add-in. Making the caller fast does not make the crossings fewer.

3. Compiled code that reads and writes in batches

Excel  →  XLL  →  compute everything in memory  →  Excel
                     ... twice, not thousands of times

Read the whole range into an array in one call, do all the work in .NET, write the whole result back in one call. Two crossings instead of hundreds of thousands. This is where an order-of-magnitude change lives, and it is an architectural change rather than a change of language.

Where the gain is large, and where it is small

The ranges below are estimates, not measurements. They come from how the two runtimes work and from the cost of each crossing into Excel. We have not run a benchmark suite, so read the table as an ordering of what stands to gain most, not as figures we recorded. There is a full note on this at the bottom of the page.

What the code spends its time on	Expected gain	Indicative range
Numeric loops and arithmetic	Large	roughly 5x to 30x
Array processing held in memory	Large	roughly 3x to 15x
String handling and pattern matching	Large	roughly 3x to 15x
Sorting, lookups and filtering	Large	roughly 3x to 20x
Reading a range once, computing, writing once	Large, and most of it comes from the batching	varies widely with the size of the range
File and network access	Small	roughly 1x to 5x, limited by the disk or the network
Reading and writing cells one at a time	Little to none	close to 1x
Waiting for Excel to recalculate	None	1x

Speed is a side effect here, and we would rather say so

Excel Armor exists to take your VBA source out of the file you ship. The business logic ends up as compiled, obfuscated .NET because that is what removes the readable source, and faster execution comes along with it. That is a real benefit, and it is not the reason the product exists.

If speed is your only problem, the cheapest fix usually costs nothing. Stop touching cells inside a loop. Read the range into a Variant array, do the work on the array, write it back in one assignment. You can do that in VBA today, without any tool, and on a cell-by-cell macro it will often beat what compiling alone would have given you.

What compiling does not speed up

Excel's own recalculation. If the workbook spends its time recalculating formulas, that clock belongs to Excel.
Cell-by-cell reads and writes. The crossing into Excel costs the same from compiled code.
Disk and network access. Opening files, hitting a database, calling a web service. The wait is outside your code.
The interface layer. UserForms and the Ribbon stay in VBA by design, so your interface keeps working exactly as it does now. That part is not compiled, and it does not need to be.
Anything that was already waiting. A macro that sits on Application.Wait, on a user, or on another program runs at the same speed in any language.

How to tell which kind your own code is

This takes about ten minutes and it beats any estimate on this page, including ours.

Time the macro as it runs today. Record the number.
Replace the cell traffic with fixed values. Comment out the reads and writes, feed the logic a constant instead, and run it again.
Compare the two numbers. If the second run is barely faster, Excel is your bottleneck: compiling will not rescue it, and restructuring the cell access will. If the second run is much faster, the time is going into your own code, and that is exactly the part compiling changes.

See where your workbook stands

Take the free 2-minute self-assessment, or read the security guide that walks through every protection method in plain language.

Free VBA protection check Download security guide (PDF)

How we arrived at these ranges

What they are based on: the architectural difference between interpreted VBA p-code and JIT-compiled .NET IL, plus the fixed cost of each crossing between an add-in and Excel. This is reasoning about how the two runtimes work, not a measurement.
What we have not done: we have not published measured numbers, because we have not measured. There is no benchmark suite behind this page. The same statement appears on our comparison page, and it holds here too.
What we intend to publish: a suite that runs the same workloads twice, once as VBA and once as the built XLL, on the same machine. When it exists, the estimates above come out and the recorded figures go in, together with the hardware and Excel version they were recorded on.
Why we will not quote a single multiplier: any "N times faster" claim about VBA to .NET is wrong for most code, because the ratio depends entirely on how much of a specific macro's time goes to calculation and how much goes to Excel. A vendor quoting one number is quoting it for a workload that is probably not yours.
Conflict of interest: Excel Armor sells the migration tool described here and has an obvious commercial interest in your conclusion. We have tried to write this page so that it stays honest in the case where compiling barely helps your code, because that case is common. If we have got something wrong, tell us.

Published by Excel Armor, which sells a VBA to VB.NET migration and protection tool and therefore has a commercial interest in your conclusion. The technical claims above describe how Excel, VBA and .NET actually work and are verifiable independently. The speed ranges are estimates and are labelled as such. Spot an error? Tell us.