> Well, converting the list to a Java native array isn't exactly going to
> be high performance to start with so converting the array to a struct
> on top of that is going to be less so.
The above doesnt really have alot of Overhead in Java Vs CFMX Vectors
In Java 1.4..
String str[];
str=String.split("delimiter");
Older versions of J2SE.. you had to use StringTokenizer Class
Vs
CFMX using list directly
Alot of ListGetAt(list, position) <-- Idea is to avoid calling ListGetAt()
20 - 50 times within any given page output.
If the lists are converted to Arrays within CFMX, they become Vectors..
Vectors(Dynamic Array of Objects) are NOT the Prefered Collection Structure
with J2SE 1.4.. i think the Java Guru's advise ArrayList Instead.
Also Native Java implemention of Map.. ie HashMap.. gives you 2 Constructors
for the size of the HashMap, so if you have fairly large structs.. the
object
doesnt have to Re-Hash.. which is considered the only OverHead of HashMap.
HashMap(int initialCapacity)
HashMap(int initialCapacity, float loadFactor)
> You could have a JavaBean that presents an array-like interface but
> manipulates the RBO lists directly and another JavaBean that presents a
> struct-like interface but manipulates the RBO lists directly
Yes, the above is exactly what i am trying to do. Depending on the type/size
of data.. gives the developer options to choose.. how he wants to get/dump
the data to the page.
I am using Native Java.. for List To Array conversion.. but have other
methods
Within CFMX Converting the Arrays to Structs.. when needed.
Now.. The performance numbers from the Test.. tell me to Move the Array To
Struct
Conversion into Native Java/JavaBean.
MAN!.. i am still curious why CFMX HashMap/Structs implementation is slower.
Only Problem.. Other CF developers in the group..dont understand Java/Alot
of the
data structure conversions etc.. so i am forced to limit Native Java usage.
> about 380hp right now with tentative plans to supercharge it :)
Nice Ride :)
Joe Eugene
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Sean A Corfield
> Sent: Sunday, June 22, 2003 11:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] Java Structs Vs CFMX Structs
>
>
> On Sunday, Jun 22, 2003, at 16:08 US/Pacific, Joe Eugene wrote:
> > 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.
>
> Interesting setup.
>
> > Since Large Java Native Arrays need to get converted to ColdFusion
> > Structs
> > for every single DB Call/Page load... This is my performance concern.
>
> Well, converting the list to a Java native array isn't exactly going to
> be high performance to start with so converting the array to a struct
> on top of that is going to be less so.
>
> However, do you actually have a performance problem with the
> architecture you have? Is it actually too slow? Does it scale poorly
> under load? Have you load tested it to establish if there is actually a
> bottleneck and where that bottleneck really is? Only if the answer to
> *all* of these questions is "yes" should you really be trying to
> optimize the code and / or the architecture.
>
> Let's assume you've done all of that and you've identified that the
> bottleneck really is converting the array to the struct (or converting
> the the list to an array in the first place!)...
>
> Why convert the list at all? It's a Java object - you could have CFMX
> manipulate it directly. If you don't like that approach, why not have
> the JavaBean act as an Adapter or an Iterator?
> http://www.mindspring.com/~mgrand/
> pattern_synopses.htm#Structural%20Patterns
> You could have a JavaBean that presents an array-like interface but
> manipulates the RBO lists directly and another JavaBean that presents a
> struct-like interface but manipulates the RBO lists directly. Make
> sense? This obviates any actual data structure conversion so it ought
> to be much faster anyway.
>
> >> If you're so concerned about performance, write your site in
> >> assembler!
> > I dont think the above would be a common sense approach.
>
> That's exactly my point!
>
> > How many of us would buy Formula One Track Cars...just because we like
> > to drive fast cars around the city.
>
> The better analogy would probably be "How many of us would *build*
> Formula One Track Cars *from scratch*..." ...but then my 'city car' is
> not exactly very sensible either:
> http://www.corfield.org/mustang/
> The page doesn't talk about all the various performance mods but it's
> about 380hp right now with tentative plans to supercharge it :)
>
> 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).
