FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

ZIGLIO, Frediano, VF-IT wrote:
> > The new function calls dbperror() for you and returns the 
> > error code, so
> > the caller can decide what to do next.  It takes the address of a
> > TDSCOLUMN pointer, which is sets.  I think it makes what's going on a
> > little clearer.  
> 
> Yes, was quite complicated... however I would prefer if dbcolptr returns
> TDSCOLUM* directly... 

Hi Freddy, 

When I decided on dbcolptr's signature, I wanted to return the error
number in case the caller needed the information.  Having finished, I see
no caller cares, so your design -- return the pointer -- would be fine. 
If you want to change it, that'd be OK with me.  Oh, I see you did!  OK! 

> of course cause it's better optimized!! Passing a
> pointer to pointer means that compiler have to allocate space in memory
> to pass the buffer while returning directly a pointer compiler can (and
> probably do) return a register. 

Maybe.  Rob Pike, to mention only one famous guy, says don't optimize
until you've measured, because bottlenecks are never where you think they
are.  In this case, I'd say:

1.  We don't know.  Too many compilers, architectures.  
2.  We don't care.  The functions aren't called often enough to matter.  

These are the API functions.  Most of them are called only a few times for
any query, at most once per column (e.g. dbcolname()).  The row-fetching
ones are called thousands of times, but they're constrained by the
server's performance. 

If I were to argue performance, I'd say dbcolptr is faster than the macro,
because the code 13X smaller.  I think you'd agree?  

The single place where performance matters in FreeTDS is buffer copies. 
*Not* because of time, but space.  A TEXT column can be 2 GB.  2 copies
can exhaust virtual memory.  Even a few copies of a 10 MB row can be a
problem.  We've seen this crop up with freebcp (IIRC) with large VARBINARY
data.  

What's more important than performance?  Clarity, surely.  The more we do
to make the code understandable, the more likely people will find bugs
themselves and/or send a patch.  Obvious code is the best tool a free
software project offers its users.  Besides, good code is more fun to work
with! ;-)

Regards, 

--jkl