there. There's simply no way to make a machine transform one language into
a second language with the same proficiency as a human writing the second
language directly. CF is an amazingly high-level language, and droping it
down to something as "primitive" as Java is an enormous task.
However, before we go too far down the road, is this topic anything we
should care tremendously about? Obviously we don't want to use slow
software, but Macromedia knows this, and they understand that if their
product offering isn't up to par performance-wise, no one will buy it (JSP,
.NET, PHP, etc. are waiting for us). We as CF developers have an interest,
but we can't do anything about MM's CF engine either way, so why even care?
<heresy>If you want a fast application server, don't use CF, pick something
else.</heresy> You'll have to deal with DB connections directly, roll your
own mailing scripts, and whatever else, but that's the tradeoff for
performance. Personally, I'm very happy making that trade.
Of course, I'd be quite interested in a discussion about how the CF engine
works, but not in a performance sense, but rather a "lets find out how it
works" sense.
Cheers,
barneyb
> -----Original Message-----
> From: Dick Applebaum [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 28, 2004 4:56 PM
> To: CF-Talk
> Subject: ROT: How does CF generated Java bytecode compare
> with Native Java bytecode
>
> There were some threads a while back that indicated the Java source
> generated by CFMX 6.0 were inefficient (big and/or slow) compared to
> the same app written in native Java.
>
> I wonder how CFMX 6.1 measures up.
>
> To narrow the comparison (a little) lets assume that there are valid
> CFMX best practices, and that the CF programmer is above average, and
> follows the best practices where warranted.
>
> Anyone have any thoughts or experiences?
>
> TIA
>
> Dick
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
