Also I want to mention that I am a heavy Mach-II user and have found it to be very high-performing. Its true that ORM layers can add a performance penalty but as Barney alluded to, that is usually because of the extreme amount of components instantiated. Both Transfer and Reactor also provide an easy way to hand-code your own SQL if you want to, as well.
On Thu, Oct 2, 2008 at 3:06 PM, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > Until you've confirmed that you have a performance problem via load > testing, don't worry about it. If you see a framework with wide > adoption, you can wager pretty safely that most of the users haven't > run into significant performance issues. At the very least, they've > found it cheaper to upgrade infrastructure than spend the extra > development dollars, but even that is pretty rare, I suspect. In > almost every case, developers are WAY more expensive than servers, so > you want to focus on optimizing the former rather than the latter. > > As for caching to resolve performance problems, those are usually > handled internally by the framework (i.e. transparent to you) if > they're needed. Most of the caching that I do is centered around > application performance (often regarding to the DB), and is not tied > to any framework I might be using. Certain "patterns" (note the > quotes of sarcasm) have arisen in the CF world for addressing the > non-performance of CFC instantiation, e.g. Iterating Business Object. > Those are often used in conjunction with frameworks, but it's not a > causal relationship. More likely, people want to use CFCs, they want > to use Framework X to help them do their job, load testing indicates > performance issues with CFC instantiation, they implement IBO to help > with that. It's bound to the decision to use CFCs not the decision to > use Framework X (though CFCs might be a prereq for X's use). > > In short, you have to figure out what works best for you. Unless > they're a single page, I never build apps without some variety of > Fusebox (usually my FB3 Lite mod) and ColdSpring. Model-Glue, > ColdSpring, and Transfer is another very common stack. I've also been > building Fusebox/ColdSpring/Groovy/Hibernate apps of late. > > cheers, > barneyb > > On Thu, Oct 2, 2008 at 12:48 PM, Jon Hall <[EMAIL PROTECTED]> wrote: > > > > Every direction I seem to go in my OO training, many suggest > > frameworks as resolutions to my problems or ways to make it easier for > > me to develop. What is some of the cost to these frameworks as far as > > performance? Alot of developers seem to use "caching" as a resolution > > to the performance costs, but isn't this just a band-aid to the real > > problem? Alot of people run their apps on VPS's and shared hosting so > > throwing more RAM & CPU at it can't be done easily, and you can only > > upgrade so far before the cost of upgrading outweighs trimming some > > fat out of the code. > > > > I read about people refactoring systems into OO Design from procedural > > and seeing a big performance hit. Sure it was easy and fast with MVC/ > > ORM/IC, but at what cost? Do alot of developers use a mix of > > frameworks depending on the application need? A data reporting system > > would benefit from MVC, but due to its simplicity would ORM be > > overkill or is the overhead minimal making it worth while? > > > > Jon > > -- > Barney Boisvert > [EMAIL PROTECTED] > http://www.barneyb.com/ > > > > -- Eric Knipp Advanced Certified ColdFusion MX Developer http://erichk.instantspot.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
