Yes, but small companies grow into large companies, and small databases and queries grow into big ones. Besides, it is possible to change a couple of _minor_ interface points on the object as provided and be a ton more performant.
For some reason, my emails seem to be taking forever to get to the list. There _should_ be a post sometime before this in which I attached a "QueryIterator2.cfc" and explain the changes. Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Farrar Sent: Thursday, February 24, 2005 12:23 PM To: [email protected] Subject: Re: [CFCDev] query object CFC Beta Joe Rinehart wrote: >Concerning efficiency, I think any code released to the outside world >as a development tool should employ the most efficient methods known >to the developer writing them. If it's an internal one-off project, I >can understand letting some stuff go, but to release something that's >a fundamental type like an iterator without having it work as >efficiently as possible probably isn't ideal, regardless of the market >(SOHO, internal, public release). > > > Efficiency has merits... but sufficient performance is the question I meant to raise. If this doesn't scale to an app that runs on superbowl night... don't use it for that app. It does scale to use on most solutions though... and I would hate to hire a programmer that spent my development dollars on testing and focusing on getting clock cycles out of the code rather than getting function to the web site. Development speed and lifecycle code management at a developers ability level is always an issue. (To him that understandeth everything is simple.) ... with that said, yes we can do things a little faster and a little this and that. In the end we get job security not because we don't think our methods are simple... but because just like it took us time to come to our methods... it takes others time also. That is the SOHO focus I refered to. SOHO companies usually don't hire people like you and me on staff do they? They don't want to pay what we can get elsewhere. Therefore... simplification of tools is a great thing! Joe... bet you don't work for a small company. Or better yet... bet if you ran a glass repair and window shop for example... you wouldn't see efficiency on the same plane as you do now. You would just want it to run consistantly. You can log pages that are running slow and tweek them rather than making every line of code streamlined. That is something us gurus forget. Programming is about more than programming. Ideals aren't always needed to the level we push them. That is why big industry creates "specs" for projects... and they don't get the "best" of everything. I agree it would be great if we could do the "most efficient" thing always... but the question is if the CFC's, TAGs and such are performing to "SPEC". This is resolved by checking page execution time. Then evaluating the bottlenecks. (In a SOHO approach that is.) Thanks for listen to my SOHO speach... heh! John Farrar ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
