Comments on: Fixing Links To UDF’s in Addins http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/ Daily posts of Excel tips…and other stuff Wed, 08 Feb 2012 23:58:05 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Simon Murphy http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/#comment-32673 Simon Murphy Wed, 04 Jun 2008 01:05:00 +0000 http://www.dailydoseofexcel.com/?p=1848#comment-32673 <p>Rob<br> I'm with you on Excel .net support, and the VSTO guys are making good progress so I hope the story improves in O14. For UDFs don't discount XLM though it can be tons faster than VBA, especially for simple stuff (loops suck big time).</p> <p>By my estimate the effort to learn C and the Excel C API = the effort to learn .net and the deployment challenges.</p> Rob
I’m with you on Excel .net support, and the VSTO guys are making good progress so I hope the story improves in O14. For UDFs don’t discount XLM though it can be tons faster than VBA, especially for simple stuff (loops suck big time).

By my estimate the effort to learn C and the Excel C API = the effort to learn .net and the deployment challenges.

]]> By: Charles Williams http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/#comment-32668 Charles Williams Tue, 03 Jun 2008 18:46:00 +0000 http://www.dailydoseofexcel.com/?p=1848#comment-32668 <p>The bug is that each execution of a UDF changes the VBE titlebar to say "Running" and then switches back, unless the calculation is initiated from VBA. The resultant VBE screen flicker and windows message flows can slow down recalc significantly.</p> <p>The problem is easily bypassed by using on-key to trap F9 etc, except in Automatic mode. The bug is present in all versions of Excel from Excel 97 through Excel 2007. Microsoft are aware of and can reproduce the bug.</p> <p>The info is on the UDFs page on my website:<br> <a href="http://www.decisionModels.com/calcsecretsj.htm" rel="nofollow">http://www.decisionModels.com/calcsecretsj.htm</a></p> <p>Automatic and Function key Calculation slower than VBA calculation</p> <p>UDFs calculate significantly slower when the calculation is started automatically by Excel or by pressing F9 than when the calculation is started by a vba calculation statement like Application.calculate.<br> The slowdown is significantly larger if the VBE is open and not minimised.<br> The slowdown is an overhead for each UDF that is recalculated, so its roughly proportional to the number of UDFs.</p> <p>These timings are for 16000 very simple UDFs, using Excel 2002 on an AMD 1200MHZ with Windows XP:<br> Autocalc with VBE open and maximised<br> 91 seconds<br> Autocalc with VBE open and minimised<br> 38 seconds<br> Autocalc with VBE closed<br> 2 seconds<br> Application.Calculatefull with VBE open and maximised<br> 0.302 seconds<br> Application.Calculatefull with VBE closed<br> 0.293 seconds</p> <p>So if you are using a lot of UDFs it really pays to be in manual calculation mode and have a calculate button that uses VBA to initiate an Excel calculation (Application.Calculate or Application.Calculatefull).</p> The bug is that each execution of a UDF changes the VBE titlebar to say “Running” and then switches back, unless the calculation is initiated from VBA. The resultant VBE screen flicker and windows message flows can slow down recalc significantly.

The problem is easily bypassed by using on-key to trap F9 etc, except in Automatic mode. The bug is present in all versions of Excel from Excel 97 through Excel 2007. Microsoft are aware of and can reproduce the bug.

The info is on the UDFs page on my website:
http://www.decisionModels.com/calcsecretsj.htm

Automatic and Function key Calculation slower than VBA calculation

UDFs calculate significantly slower when the calculation is started automatically by Excel or by pressing F9 than when the calculation is started by a vba calculation statement like Application.calculate.
The slowdown is significantly larger if the VBE is open and not minimised.
The slowdown is an overhead for each UDF that is recalculated, so its roughly proportional to the number of UDFs.

These timings are for 16000 very simple UDFs, using Excel 2002 on an AMD 1200MHZ with Windows XP:
Autocalc with VBE open and maximised
91 seconds
Autocalc with VBE open and minimised
38 seconds
Autocalc with VBE closed
2 seconds
Application.Calculatefull with VBE open and maximised
0.302 seconds
Application.Calculatefull with VBE closed
0.293 seconds

So if you are using a lot of UDFs it really pays to be in manual calculation mode and have a calculate button that uses VBA to initiate an Excel calculation (Application.Calculate or Application.Calculatefull).

]]> By: Doug Glancy http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/#comment-32667 Doug Glancy Tue, 03 Jun 2008 18:00:00 +0000 http://www.dailydoseofexcel.com/?p=1848#comment-32667 <p>Charles, What's the "VBE refresh slowdown bug?" I googled, including with your business name, but nothing leapt out at me.</p> Charles, What’s the “VBE refresh slowdown bug?” I googled, including with your business name, but nothing leapt out at me.

]]> By: Charles Williams http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/#comment-32663 Charles Williams Tue, 03 Jun 2008 11:37:00 +0000 http://www.dailydoseofexcel.com/?p=1848#comment-32663 <p>If you wanted a fully-supported .Net solution you could try Jens Thiel managed XLL. I have not used it myself but i hear good reports (It also bypasses the marshalling problem in favour of the C API).</p> <p>Technology timing comparison for one particular test UDF:<br> VBA 1.5<br> VB6 1.4<br> c# 9.1<br> c++ 0.88</p> <p>As you can see the C# performance is truly appalling: this is supposed to be down to the marshalling layer.</p> <p>In many cases compiled VB6 does not run any faster than VBA, probably because most of the time is either spent in data transfer between Excel and VB or in the VB runtime.<br> Even the most calculation-intensive UDF I have only showed a small (10-15%) improvement with a compiled VB6 automation addin.</p> <p>(the VBA timings all bypass the VBE refresh slowdown bug)</p> If you wanted a fully-supported .Net solution you could try Jens Thiel managed XLL. I have not used it myself but i hear good reports (It also bypasses the marshalling problem in favour of the C API).

Technology timing comparison for one particular test UDF:
VBA 1.5
VB6 1.4
c# 9.1
c++ 0.88

As you can see the C# performance is truly appalling: this is supposed to be down to the marshalling layer.

In many cases compiled VB6 does not run any faster than VBA, probably because most of the time is either spent in data transfer between Excel and VB or in the VB runtime.
Even the most calculation-intensive UDF I have only showed a small (10-15%) improvement with a compiled VB6 automation addin.

(the VBA timings all bypass the VBE refresh slowdown bug)

]]> By: Rob van Gelder http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/#comment-32659 Rob van Gelder Tue, 03 Jun 2008 09:47:00 +0000 http://www.dailydoseofexcel.com/?p=1848#comment-32659 <p>I recently downloaded ExcelDNA, but that's as far as I got. Development appears stalled, and looks experimental... not really something I want to throw at my customers.<br> To be honest, I just want Excel to support .NET libraries as add-ins out of the box. Oh, and I want a .NET flavoured RefEdit control.</p> <p>I wonder why automation add-ins with C# perform rubbish? I would have expected VB6 compiled to perform worse. I need to look into that, I think :)<br> Cheers for the tip, I didn't click that VS.NET can do COM.</p> I recently downloaded ExcelDNA, but that’s as far as I got. Development appears stalled, and looks experimental… not really something I want to throw at my customers.
To be honest, I just want Excel to support .NET libraries as add-ins out of the box. Oh, and I want a .NET flavoured RefEdit control.

I wonder why automation add-ins with C# perform rubbish? I would have expected VB6 compiled to perform worse. I need to look into that, I think :)
Cheers for the tip, I didn’t click that VS.NET can do COM.

]]> By: Simon Murphy http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/#comment-32658 Simon Murphy Tue, 03 Jun 2008 09:27:00 +0000 http://www.dailydoseofexcel.com/?p=1848#comment-32658 <p>Rob<br> You can write automation add-ins with C# but the performance is rubbish. But there is an open source project called ExcelDNA that allows you to write C# UDFs, it passes them through the xll interface so they perform well.</p> Rob
You can write automation add-ins with C# but the performance is rubbish. But there is an open source project called ExcelDNA that allows you to write C# UDFs, it passes them through the xll interface so they perform well.

]]> By: Rob van Gelder http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/#comment-32655 Rob van Gelder Tue, 03 Jun 2008 06:40:00 +0000 http://www.dailydoseofexcel.com/?p=1848#comment-32655 <p>The trouble is Excel tries to use relative paths wherever possible. I recall having problems with users creating workbooks (that relied on my addin) from their C: drive, and trying to publish them on the network drive.</p> <p>I also dabbled with VBA References to the XLA, which worked ok, but had similar problems with path locations.</p> <p>In the end, I settled on the COM automation add-in (a feature of Excel 2002 onward), because it did not track path locations.<br> The only down side (and this is a minor issue, really!) is that you get funky looking dotted function names prior to the first successful calculations eg. =MyAddIn.MyFunction() before, and =MyFunction() after.<br> This was an issue for me because I had a custom right-click context menu for breaking the formula into tokens for a formula builder screen. It was never an issue for the users.<br> Automation Add-Ins are great.</p> <p>Ideally, I would have used XLL, but I don't have the programming experience with C++ to make it as rock solid as I required.<br> I'd love to write Excel UDFs in Visual Studio C#, but (I believe) only pay solutions exist so far, eg managedxll.</p> The trouble is Excel tries to use relative paths wherever possible. I recall having problems with users creating workbooks (that relied on my addin) from their C: drive, and trying to publish them on the network drive.

I also dabbled with VBA References to the XLA, which worked ok, but had similar problems with path locations.

In the end, I settled on the COM automation add-in (a feature of Excel 2002 onward), because it did not track path locations.
The only down side (and this is a minor issue, really!) is that you get funky looking dotted function names prior to the first successful calculations eg. =MyAddIn.MyFunction() before, and =MyFunction() after.
This was an issue for me because I had a custom right-click context menu for breaking the formula into tokens for a formula builder screen. It was never an issue for the users.
Automation Add-Ins are great.

Ideally, I would have used XLL, but I don’t have the programming experience with C++ to make it as rock solid as I required.
I’d love to write Excel UDFs in Visual Studio C#, but (I believe) only pay solutions exist so far, eg managedxll.

]]>