I have discovered that using enumerators (over an array of tuples) is VERY expensive relative to simply indexing through the same array and binding the tuples with a let. This code occurs within my NPuzzle sample which is described in the "F# Excessive Consing ..." thread in this same group. Here's the code in question (which happens to be the "hot spot" performance wise in my puzzle solver.):

1
2
3
4
5
6
7

for j = 0 to Puzzle.RowColumns.Length - 1 do
 let (r,c) = Puzzle.RowColumns.[j]
//for (r,c) in Puzzle.RowColumns do
 let position = r * Puzzle.PuzzleSize + c in
  let tile = board.[position]
  if tile <> BlankCell then total <- total + abs(r - int(tile)/Puzzle.PuzzleSize) + abs(c - int(tile) % Puzzle.PuzzleSize)
done

The two cases to consider can be seen in the first 3 lines above. The "fast" version is as presented above. The "slow" version is obtained by commenting out the first 2 lines and uncommenting the 3rd line. The performance difference is pretty dramatic. For my largest NPuzzle case the "fast" version completes in 1.044 seconds while the slow version completes in 6.950 seconds which is ~7x slower! Further, the "fast" version requires (6388, 104, 10) garbage collections, where generation 0, 1,2 collections are counted. The "slow" version requires (82439, 694, 69) garbage collections. This is 13x more generation 0 collections for the "slow" version!

This result seems (to me) to violate the principal of least astonishment. Since the tuple binding occurs in both cases, the only (obvious) remaining difference is the use of the enumerator for the array in the "slow" case. While I would expect *some* overhead given the hidden function calls, 7x seems excessive; furthermore I have no explanation for the huge increase in garbage collections.

Can anyone explain these differences? Is this expected?

Thanks in advance,

Bill