The scalability in using application scope should be the deciding factor. The overhead in creating and reading request variables per request, I would have thought, would be high vs. using a persistant scope that is only created/written to when it doesn't exist.
Darryl Lyons http://dangermoose.blogspot.com [EMAIL PROTECTED] wrote on 21/04/2005 09:40:14 AM: > Well if its simple variables, then I'm unsure as to what increase in > memory they have? > > ie if you store a string in say 20 variables ... > > what gains do you get for Application scoping vs request? in that > 1byte per variable? whats the acid test for vars on request vs > application. > > *deep ponder voice* > hmmmmmmmmmmmmmmmmmm... > > > On 4/21/05, Darryl Lyons <[EMAIL PROTECTED]> wrote: > > I would have to agree there. Surely, the amount of memory needed for > > 10xRequest-scoped variablesxPage requests would be more than > > 10xApplication-scoped variables. > > > > Darryl Lyons > > http://dangermoose.blogspot.com > > > > [EMAIL PROTECTED] wrote on 21/04/2005 09:09:16 AM: > > > > > Scott, > > > > > > I will also but my hand up and ask if there is any performance > > difference in > > > setting for each request to one checking if it exists for an entire > > > application. Might I also add that I would have thought that in the > > > application scope on a high traffic site would mean using less memory as > > > well! > > > > > > > > > > > > Regards > > > Andrew Scott > > > Technical Consultant > > > > > > NuSphere Pty Ltd > > > Level 2/33 Bank Street > > > South Melbourne, Victoria, 3205 > > > > > > Phone: 03 9686 0485 - Fax: 03 9699 7976 > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Scott > > Barnes > > > Sent: Wednesday, 20 April 2005 8:11 PM > > > To: CFAussie Mailing List > > > Subject: [cfaussie] Re: Managing application constants > > > > > > Well, I personally keep them rolled up into a configObject as typically > > when > > > i need constants its used in both my cfc's and my normal cfm. > > > > > > That being said, i don't want to roll that information per request as > > the > > > configObject pretty much has the global crap inside it..and yes i'm > > going to > > > bring out that OO bible and preech thine singleton to thee. As I use xml > > to > > > define some settings at times - what can i say, i have a chubby for a > > > mach-ii sytle approach in development - its rapid so back off man. > > > > > > Depends on the app in the end, my option can be long winded for a really > > > small app that has like zero need for a complex solution like the above. > > > > > > hmm as for seans why not use request in the end... good question. In > > that do > > > you get any real gains by using CFIF > > > StructKeyExists(application,"keyToSettings") THEN initialize vars... > > > vs just rolling them inside request vars? if they are simple? > > > > > > I've noticed that a lot and now that he brings it out to air, i wonder > > > ...*in a deep pondering voice* hmmmmmmmmmmmmm.... > > > > > > > > > On 4/20/05, Sean Corfield <[EMAIL PROTECTED]> wrote: > > > > On 4/19/05, Ryan Sabir <[EMAIL PROTECTED]> wrote: > > > > > <CFSET request.dsn = "blah"> > > > > ... > > > > > What's the best practice in this case? > > > > > > > > I'd go with request scope. Why put this in application scope? What > > > > benefit do you get from using application scope for simple variables > > > > here? > > > > -- > > > > Sean A Corfield -- http://corfield.org/ Team Fusebox -- > > > > http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give > > > > away! > > > > > > > > "If you're not annoying somebody, you're not really alive." > > > > -- Margaret Atwood > > > > > > > > --- > > > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To > > > > > > unsubscribe send a blank email to > > > > [EMAIL PROTECTED] > > > > Aussie Macromedia Developers: http://lists.daemon.com.au/ > > > > > > > > > > > > > -- > > > Regards, > > > Scott Barnes > > > http://www.mossyblog.com > > > http://www.flexcoder.com (Coming Soon) > > > > > > --- > > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To > > unsubscribe > > > send a blank email to [EMAIL PROTECTED] > > > Aussie Macromedia Developers: http://lists.daemon.com.au/ > > > > > > > > > > > > > > > --- > > > You are currently subscribed to cfaussie as: > > [EMAIL PROTECTED] > > > To unsubscribe send a blank email to > > [EMAIL PROTECTED] > > > Aussie Macromedia Developers: http://lists.daemon.com.au/ > > > > To unsubscribe from this email please forward this email to > [EMAIL PROTECTED] > > > > This email message is confidential and may be privileged. > Unauthorised use, copying or distribution of any part of this email > > including attachments is prohibited. If you are not the intended > recipient please forward the email to [EMAIL PROTECTED] > > and delete the original. > > > > ABN AMRO Morgans Limited and its associates hold or may hold > securities in the companies/trusts mentioned herein. Any general > > advice included in this email has been prepared without taking > into account your objectives, financial situation or needs. Before > > acting on the advice, you should consider its appropriateness or > discuss with one of our investment advisors. > > > > To the extent permitted by law we exclude (and where the law does > not permit an exclusion, limit to the extent permitted by law) all > > liability for any direct, indirect and consequential costs, > losses, damages and expenses incurred in any way (including but not limited > > to that arising from negligence), connected with any use or access > to this email or any reliance on information contained in this email > > or any attachments. > > > > ABN AMRO Morgans Limited (ABN 49 010 669 726 AFSL 235410) A > Participant of ASX Group A Principal Member of the > > Financial Planning Association > > > > > > --- > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > > To unsubscribe send a blank email to [EMAIL PROTECTED] > daemon.com.au > > Aussie Macromedia Developers: http://lists.daemon.com.au/ > > > > > -- > Regards, > Scott Barnes > http://www.mossyblog.com > http://www.flexcoder.com (Coming Soon) > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to [EMAIL PROTECTED] > Aussie Macromedia Developers: http://lists.daemon.com.au/ To unsubscribe from this email please forward this email to [EMAIL PROTECTED] This email message is confidential and may be privileged. Unauthorised use, copying or distribution of any part of this email including attachments is prohibited. If you are not the intended recipient please forward the email to [EMAIL PROTECTED] and delete the original. ABN AMRO Morgans Limited and its associates hold or may hold securities in the companies/trusts mentioned herein. Any general advice included in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on the advice, you should consider its appropriateness or discuss with one of our investment advisors. To the extent permitted by law we exclude (and where the law does not permit an exclusion, limit to the extent permitted by law) all liability for any direct, indirect and consequential costs, losses, damages and expenses incurred in any way (including but not limited to that arising from negligence), connected with any use or access to this email or any reliance on information contained in this email or any attachments. ABN AMRO Morgans Limited (ABN 49 010 669 726 AFSL 235410) A Participant of ASX Group A Principal Member of the Financial Planning Association --- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
