> This is kind of an old thread that keeps coming up... folks write a > little test loop and worry about something being faster / slower one > way than another. The performance differences you're seeing are really > unimportant in the long-run and you'd be much better off worrying about > bigger issues (like software architecture, user interaction etc).
This has to do with Architecture... and this is why i am concerned. Briefly.. 1. Multi-Value DB U2(UniVerse) 2. Middle Tier Object Server (RedBack) 3. CFMX Front End. The frontend(CFMX) does NOT talk to DB Directly... CFMX Communicates with RedBack Objects(RBO) on the RedBack Server that talks to DB and does all the Business Logic. Now Data is Returned from RBO's as LISTS NOT ResultSets. I wrote a JavaBean.. interface to communicate with RBO's and take the LISTS and return them as arrays natively. Now.. Dumping the data on the Front end via Arrays is not very clean.. and we need Key-Value pairs in many Instances.. Since Large Java Native Arrays need to get converted to ColdFusion Structs for every single DB Call/Page load... This is my performance concern. > If you're so concerned about performance, write your site in assembler! I dont think the above would be a common sense approach. How many of us would buy Formula One Track Cars...just because we like to drive fast cars around the city. Joe Eugene > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sean A Corfield > Sent: Sunday, June 22, 2003 6:01 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Java Structs Vs CFMX Structs > > > On Sunday, Jun 22, 2003, at 14:36 US/Pacific, Joe Eugene wrote: > > I am not sure...how the internals of CFMX Implementation makes > > quite some difference in the performance of code. > > This is kind of an old thread that keeps coming up... folks write a > little test loop and worry about something being faster / slower one > way than another. The performance differences you're seeing are really > unimportant in the long-run and you'd be much better off worrying about > bigger issues (like software architecture, user interaction etc). > > Build it using good design, see how it performs, load test it and tune > it. Most performance improvements come from using a better algorithm - > not from some one-line code tweak. > > > Does anybody suggest going the Java route for better performance? > > If you're so concerned about performance, write your site in assembler! > > I just spent a week at JavaOne and focused on the performance-related > sessions since I'm very interested in performance at large. Here's the > links to my blog entries about those sessions: > > Garbage Collection: > http://www.corfield.org/ > index.php?fuseaction=blog.archive&month=2003_06#000399 > > Five Secrets to Faster Code: > http://www.corfield.org/ > index.php?fuseaction=blog.archive&month=2003_06#000398 > Note in particular: "Above all, start with readable code - it's easier > to maintain, it's easier to tune and HotSpot will do a better job of > optimizing it." > > Benchmarking: > http://www.corfield.org/ > index.php?fuseaction=blog.archive&month=2003_06#000393 > > Performance Monitoring: > http://www.corfield.org/ > index.php?fuseaction=blog.archive&month=2003_06#000392 > > Platform Performance: > http://www.corfield.org/ > index.php?fuseaction=blog.archive&month=2003_06#000388 > > Sean A Corfield -- http://www.corfield.org/blog/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
