Question

http://msdn.microsoft.com/en-us/library/microsoft.office.tools.excel.worksheet.get_range.aspx it says to use the Range property instead of get_Range(Object Cell1, Object Cell2).

They are both doing the same thing, Gets a Microsoft.Office.Interop.Excel.Range object that represents a cell or a range of cells. So, what’s the difference except that this is a method and another is a property? Why are they pointing on use of Range[], what’s the reason for it?

Answer 1

Range() is faster than Range[]

By practice we have noticed it the case. But here should define a reason to say so.

This shortcut is convenient when you want to refer to an absolute range. However, it is not as flexible as the Rangeproperty as it cannot handle variable input as strings or object references. So at the end of the day you will still end up referring the long way. Although the shorty provides readability. Hence might as well get it right the first round without more resources spending.

Now why is it slow? In the compiling.

“During run-time Excel always uses conventional notation (or so I’ve been told), so when the code is being compiled all references in shortcut notation must be converted to conventional range form (or so I’ve been told). {ie [A150] must be converted to Range(“A150”) form}. Whatever the truth of what I’ve been told, Visual Basic has to memorize both its compiled version of the code and whatever notation you used to write your code (i.e. whatever’s in the code module), the workbook properties for the file size (the memory used) thus goes up slightly. “

As you see my answer was more in line with VBA. However after some research it is sort of proved that VBA side doesn’t do much slowing down. So you only need to take care of the C# side. @Hans gives you a better answer in C# perspective. Hope combining both that you will get a great performing code 🙂

Here is some finding on the performance of Range[] vs Range() in Excel