Comments on: Arrays Explained

By: Bob Phillips

Bob Phillips — Thu, 08 Jan 2009 22:53:00 +0000

I set my arrays at some pre-deterimed size, and if I fill it, I double it. At the end I ReDim to the required size.

By: Jon Peltier

Jon Peltier — Thu, 08 Jan 2009 16:15:00 +0000

I like having a definite upper bound, because often my arrays go back into the worksheet. Sometimes I’ll run through a loop once to count how many rows my array will need, create the array, then populate it. I don’t really know what the performance hit is, but usually in my apps, the time spent waiting for the user to scratch his head and click something is far far longer.

By: Jan Karel Pieterse

Jan Karel Pieterse — Thu, 08 Jan 2009 07:29:00 +0000

On some apps, fast *is* preferable over easy to read. Charles Williams and I enhanced the performance of our Name Manager quite a bit for workbooks with many range names (over a 100) and it helped to make the app usable in such situations.

By: Jan

Jan — Wed, 07 Jan 2009 22:09:00 +0000

Doubling sounds good, but perhaps we should consider +10% increments like SQL Server defaults to on its table space allocation growth.

I am a combination of lazy and clean, so I prefer to increment by 1. I think if you use Excel VBA, easy to read code is much better than fast but complex code.

Also some functions require an Array of an exact size, for exampe the Sheets(Array("Sheet1?,"Sheet2?)).select and if you had a huge array with empty gaps then the code would fail.

By: fzz

fzz — Wed, 07 Jan 2009 06:03:00 +0000

First text in which I read about doubling array bound was Kernighan & Pike's 'The Practice of Programming'. I figure everyone else in Bell Labs was using this approach for years before it found its way into this book. And they probably took this from someone else back in the 1980s. Regardless, it ain't new.

1D arrays are very useful. 2D arrays a little less so, thogh very handy for interfacing with ranges. Higher dimension arrays are usually much less useful compared to other structures in my experience.

By: Jon Peltier

Jon Peltier — Wed, 07 Jan 2009 01:25:00 +0000

Doug -

For a text file that has rows separated by CR or LF, you could read the entire file into a string, then use Split to construct your array.

Depending on the application, I have sometimes first converted CSV files into an array of rows by splitting at the CR/LF, then converted each row into an array by splitting at the tab character. You reference the elements using Array(i)(j) instead of Array(i,j), but I guess that's about the only difference.

By: Doug Jenkins

Doug Jenkins — Tue, 06 Jan 2009 23:27:00 +0000

I too am a big fan of arrays, and I don't care at all if they are "obsolete". Since worksheet ranges are in effect 2D arrays it makes sense to me to use them in VBA. The ease with which data is passed from a worksheet range to a VBA variant is an added bonus, and the fact that much engineering analysis involves working with matrices (which is just another name for arrays) makes them the obvious choice.

In nearly all cases I will know (or be able to calculate) the array size, based on the size of the range/array passed from the spreadsheet, so there will only be a need for at most one re-dim at the start. The only one of my applications I can think of immediately where this doesn't apply are functions/subs for reading text files. In this case I step through the file first to count the number of rows, then redim an array, then read each line into the array. That sounds hopelessly inefficient, but in practice it adds hardly anything to the execution time. An alternative would be to just dimension the array to the maximum number of rows in a spreadsheet.

I tend to use arrays with named ranges, then to write the entire contents of an array to a named range:

With Range("MyNamedRange")
.Resize(NumArrayRows, NumArrayColumns).Name = "MyNamedRange"
.Value = MyArray
End With

This works virtually instantaneously, even with huge ranges. The improvement in performance compared with writing cell by cell is likely to be a factor of tens or hundreds (or compared with cell by cell writing with auto-recalc still enabled, thousands).

More here: http://newtonexcelbach.wordpress.com/2008/03/05/ranges-and-arrays-2/

By: Charles Williams

Charles Williams — Tue, 06 Jan 2009 21:05:00 +0000

When you read a range into a variant you don't need to redim it anyway, and this is much the most efficient way of transferring data from Excel to VBA. For example -

Dim vArr as variant
vArr=Range("A1").resize(Range("A65536").end(xlup).row,2)

Otherwise I either Dim the Array to the max possible size or double it.

Usually its not worth bothering to do a final Redim Preserve to shrink the array unless you are assigning the array back to a Range.

By: Dick Kusleika

Dick Kusleika — Tue, 06 Jan 2009 20:56:00 +0000

Mathias: Escape any less-than signs in your code or it will get cut off.

Jon: Because I'm just doing the array work inside the class, so why not just do it where I need it. OK, there are good reasons for having it in the class, but it only moves the implementation questions.

By: Jon Peltier

Jon Peltier — Tue, 06 Jan 2009 20:45:00 +0000

Dick -

If you built a SmartArray class, why wouldn't you include methods to populate the array from a range, or dump the array's contents into a range?