Fog Creek Software
Discussion Board




Recordset.collect

Why do programmers insist on doing stuff like this.

One of the programmers who worked on the code I now maintain insisted on always using Recordset.collect

Recordset.collect is an undocumented feature similar to field.  Rather than Recordset.field("Name") you say Recordset.collect(3).  It's supposed to be 30% faster.

Is this speed up really worth the cost in maintainability.  You think he could of at least have declared constants for the field names!  This recordset has over 200 fields (no normalisation either.)

Why are some developers so obsessed with performance!  Every other programmer used the proper field("Name") and there is no perceptible difference in performance.

Ged Byrne
Friday, August 15, 2003


  I've been there.  Once I had to mantain a code that had some records declared just like that:

  Type = Record
        LongData: array of Long[1..10];
        StringData: array of String[1..5];
  (...)


  You can imagine the headache I had.

 

Ricardo Antunes da Costa
Friday, August 15, 2003

Ged,

I think it's because people see something like "using Recordset.Collect is up to 30% faster than using..." recommended in some "Microsoft's 10 Top ADO Performance Tips" whitepaper and take it as gospel.

It's like the similar tip of using "Response.Write" to spit out HTML instead of intermixing script and HTML on an ASP page.

Guy Incognito
Friday, August 15, 2003

Well if he is guilty, then I am too. I am guilty for using ADO.Command from time to time on batch jobs that must deal with lots of data.

Li-fan Chen
Friday, August 15, 2003

This isn't lots of data, its GUI code.

When there is lots of data, he has these painfully complex loops through recordsets on the server.  Pages of code the purpose of which is practically impossible to fathom (No field names, just lots of numbers) but I'm confident it could be more understandable and a helovalot faster as SQL.

Ged Byrne
Friday, August 15, 2003

*  Recent Topics

*  Fog Creek Home