Forum OpenACS Q&A: Re: Just the database API

Collapse
11: Re: Just the database API (response to 1)
Posted by Don Baccus on
Writing it in C would just increase the maintenance headache and make it harder for people to customize things to please themselves.  The API does very little except call the DB and create variables in the caller's space.  I'm sure the DB overhead swamps all.

There's no real advantage to having it as a module, a set of Tcl procs that are sourced at start-up are just fine.

Collapse
Posted by Andrew Piskorski on
I think Jeff Davis was talking once on IRC about the possibility of re-writing the db_api to eliminate the use of ns_set in the ns_db API, in order to remove a lot of the string copying and Tcl string/object conversion overhead. However, I don't remember if he was just speculating wildly, or if he had a real-world case where the extra string processing overhead was significant and worth the trouble to avoid.

Personally I'd be surprised if the string overhead was significant enough to justify the hassle of using some other than the standard ns_db API. But, anyone curious should probably ask Jeff...

Collapse
Posted by Jeff Davis on
It mattered but this was for a page that was constructed from about 2k rows (aggregation of company financials where each table element came from one or more rows). In most cases this would not make that much of a difference. I did some testing and it looked like by going directly to tcl variables from the db you might cut the time on a query like that by 25% or so. I makes sense that it would matter for the some things for the same reason that whenever you read things about expr it tells you to use { }'s.

It's not that common a use case though.

The other thing was that tcl's handling of floats and ints etc is problematic. This turned up when doing these financial calculations since you would have round numbers going into a formula and get the wrong result like this:

% set x 1
1
% set y 3
3
% expr $x / $y
0
I also thought about making it so that floats were returned with .0 tacked on to avoid this sort of problem.