Performance is relative to the actual application code running within the implementation of a pattern. An empty shell implementation with no DB or file system calls will be very efficient. If any part of the implementation contains poorly crafted DB and logic code then the thing will not perform well in any case.
In other words; Performance is relative to the actual work being done and the code doing the work, so having performance examples; while being of some illustrative value in terms of the number of calls being made within a pattern, is still not going to give you useful performance data unless you add all of the working code to the objects. Take for example an object that contains a method which queries a DB, if that code is SQL at the template level and cached or not the performance will be lower than the same object / method making use of a stored procedure for the query. In this case the pattern itself, while having some small part to play in the performance is practically irrelevant. The overhead of the query and the hidden costs at the DB in terms of the execution plan etc have the greatest impact on performance. So, unless you can account for the costs of the actual DB and application transactions as captured within the realization of a pattern during the conceptual representation and design of the application using the pattern(s) then attempts to represent even "baseline" performance will prove very difficult indeed. Can you provide an example of how you might use big-O notation to address performance issues within a pattern where the actual complexity is not solely expressed in terms of the number of objects/methods that represent the pattern but in the queries and application logic as embodied as transactions and algorithms invoked during the use of the end product application? I can see using big-O notation as a means to measure a specific algorithm within a method or even as a means to measure a transaction where the number of elements and processes in the transaction are known as well as the specific volume and content of the data is known. I'm just not clear on how to apply it to a pattern in an abstract form where there is no application logic and where that logic will vary from application to application. Byron PS. I've been reading this thread and I think it's a great idea, a live document (livedocs??) community knowledge base around patterns and CF is long overdue. B -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hagan, Ryan Mr (Contractor ACI) Sent: Friday, July 23, 2004 8:31 AM To: '[EMAIL PROTECTED]' Subject: RE: [CFCDev] Design Patterns or Advanced CF Yeah, well, call me crazy, but what about some form of Big-O notation for web based patterns. In Computer Science and Mathematics, we use big-o to describe the performance cost of different algorithms in simple terms. Why not find a way to describe the cost of different patterns? I agree that the main goal is to have maintainable code, but why not provide some type of performance cost? -----Original Message----- From: Stijn Dreezen [mailto:[EMAIL PROTECTED] Sent: Friday, July 23, 2004 8:14 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Design Patterns or Advanced CF I don't see why i should be joking, but if you want me to, i will. I didn't say i want streamlined, optimized examples but a rough performance cost estimation for these patterns is definitely something I would like very much, for i don't about your vast hardware resources but i sure know that almost each application i wrote in cf sooner or later came to a point where performance DID matter. For all my latest applications even BOTH (design patterns AND performance) were part of the technical specifications, as it is standard procedure in developing applications in our team at the European Council. But maybe they're just joking as well :) That already makes it 3 cents i guess :) kind Regards Stijn Dreezen On Thu, 22 Jul 2004, Sean Corfield wrote: > Please tell me you're joking? > > People use patterns to improve maintainability, not to improve > performance (with one or two notable exceptions, of course). > > What is this obsession with "millisecond" level performance? (Which > has nothing to do with real world performance under load) > > On Thu, 22 Jul 2004 23:39:08 +0200 (CEST), Stijn Dreezen > <[EMAIL PROTECTED]> wrote: > > At least pay some attention to performance (which pattern is better suited > > for which kind of application, how much milliseconds the pattern framework > > would consume on average systems, ...). One Spectra 1.5 has already been > > enough ;) > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
