Hi John, > 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.
Right - I think that's a valid tradeoff statement to make. I think in developing something like an iterator component, which is broad-target / wide-use, there's a high performance responsibility. The GetColumn(columnname) that Ben suggested speeds up the component drastically, and may be a necessary tradeoff. It also solves the "this"-scope naming conflicts problem. > 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. I'd like to see more programmers and developers actually bother to load test before sending stuff to QA. > 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. If we already know about it, we should do it! > 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. I've worked for / do work for a number of small companies on a contract basis - one of my selling points is that I'm going to give them the same quality I give my fulltime job. Part of that quality is simplification of tools. Complexity management is increasingly important as the size of companies and projects grows, so simple tools are important everywhere, not just to the SOHO crowd. The same SOHO crowd, when they're paying me on an hourly basis, expect me to readily available components instead of re-inventing wheels. CF's query object works great, and has for years. I'd have a hard time selling them a "new" version that is slower than the older version and doesn't give me any advantage. > 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. In a smaller business where budgets are likely to be tighter, I'd want the maximum efficiency possible with disrupting my customer experience. In terms of a small web shop that wants to grow, efficiency can mean the difference between massive expenditures on hardware and making do with what already exists. > 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. Right, but I think some ideals are in place for a reason. Having this iterator by-value copy its contents into a public property is just, well, unnecessary, especially when the already established interface for this sort of thing in ADO.NET and other languages is a getColumn() method. Why not boost performance and give developers an interface they're already used to? > 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.) This is low-level, but I have a hard time really performance-tuning my CFCs by watching execution time. I know the CF timer has a hard time with small units of time, but I really hate seeing all those 16ms method calls and not knowing if it really took 16ms. Another reason to tune ahead of time in CFCs. > Thanks for listen to my SOHO speach... heh! No problem - thanks for making it a good discussion. It's really cool to be able to disagree without flaming each other :). -- For Tabs, Trees, and more, use the jComponents: http://clearsoftware.net/client/jComponents.cfm ---------------------------------------------------------- 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]
