VB.NET vs CFMX tick count distribution?

[Brett]

I have compared, in ms, the time VB.NET and CFMX take to execute code that
is nearly exact in their respective languages. The tick count distributions
in VB.NET are very tight, ranging from 154 - 190 with no outliers. The CFMX
code is distributed in the range 356 - 950 and one outlier at 1356. Why is
the VB.NET code distributed very tightly against the mean vs. the CFMX code?

Thanks,
Brett

 

[Samuel R. Neff]

You'll have to be more specific--post the code (both vb.net and cfml).

Sam

 

[Brett]

ok, the code follows. Both languags are connecting to a mail server,
downloading messages and then displaying each by looping.

-- CFMX --

<cfscript>
ipworksPOPobj = structnew();
ipworksPOPobj = CreateObject("com", "IPWorksASP5.POP");
ipworksPOPobj.MailServer = "mail.abc.com";
ipworksPOPobj.user = "(e-mail address removed)";
ipworksPOPobj.password = "test";
ipworksPOPobj.connect();
</cfscript>

<cfloop from="1" to="#ipworksPOPobj.MessageCount#" index="iMesgNo">
<cfoutput>
<cfset ipworksPOPobj.MessageNumber = iMesgNo>
<cfset ipworksPOPobj.Retrieve()>
Subject: #ipworksPOPobj.MessageSubject#<br>
To: #ipworksPOPobj.MessageTo#<br>
Date: #ipworksPOPobj.MessageDate#<br>
From: #ipworksPOPobj.MessageFrom#<br>
#ipworksPOPobj.MessageHeaders#<br><br>
#htmleditformat(ipworksPOPobj.MessageText)#<br><br>-------------<br><br>
</cfoutput>
</cfloop>
<cfset ipworksPOPobj.Disconnect()>



-- VB.NET --

Dim starttime As Integer
Label1.Text = ""
starttime = Environment.TickCount
Dim mail As New Pop3Mail
ProgressBar1.PerformStep()
mail.Connect("mail.abc.com", "(e-mail address removed)", "test")
ProgressBar1.PerformStep()
For Each msg As Pop3Mail.Pop3Message In mail.List
ProgressBar1.PerformStep()

Label1.Text = TextBox1.Text & DirectCast(mail.Retrieve(msg),
Pop3Mail.Pop3Message).message
Next
Label1.Text = (Environment.TickCount - starttime) & "- -" & Label1.Text
starttime = 0


The VB.NET POP3Mail methods are those provided by Ken Tucker (see thread
'Downloading mail through VB.NET' @ 11:46A on 12/30/04)

Hope that helps.

Thanks,
Brett

 

[Samuel R. Neff]

The problem is probably related to the fact that you're using a COM
object in CFMX when you don't need to. If you were to marshall the
vb.net call through a pure java jar file (not a J# compiled java file,
but real java bytecode) then you'd most likely see the same slower
speed and variability.

Try using <cfpop> instead or at least the built-in javamail options
instead of a COM object. That will improve the CFMX performance and
reduce the variability.

HTH,

Sam

 

[Brett]

Thank you. What is causing the variability? How do I investigate this?

You are saying if I use cfpop, then the CFMX would be about as fast as
VB.NET? I always thought VB.NET would be much faster than a scripting
language for comparable code. Can you comment on this?

From what I gather, if I use IPWorks VB version in VB.NET, this would slow
down overall performance in VB.NET? I thought it would enhance performance
since IPWorks specializes in this area. Please comment.

Kind regards,
Brett Romero

 

[Samuel R. Neff]

Both CFML and VB.NET are compiled languages that compile down to
intermediate code--CFML to java bytecode and VB.NET to msil. There
will be some performance differences but nothing like comparing a
scripting language to a compiled language. CF5 and earlier were
scripted languages, but that's no longer the case. CFMX gets directly
compiled to Java bytecode.

There are a lot of factors that can cause the variability. Whenever
you use non-native technologies you're going to see some incrased
variability and decreased performance--like COM from Java (CFMX) and
Java from .NET. Probably even to a certain degree COM from .NET.

Using a COM oject from .NET will most likely slow down performance vs.
a native object--it really depends on how much processing is done by
the object and whether the decreased performance of the method call
can be overcome by increased performance of the method itself (if
there really is increased performance in the COM object). But there's
also the additional factor that not all "native" classes in .NET are
really native to .NET, many of them are wrappers around existing Win32
and COM objects. So you may be using a COM object in .NET and not
even know it. However, the advantage of using a .NET object is that
going forward you'll most likely see some of them transition to native
code that previously used other objects with an associated increase in
performance.

HTH,

Sam

 

[Brett]

Whenever you use non-native technologies you're going to see some incrased

variability and decreased performance

I can understand decreased performance in the above scenario but why
variability? Say I have a COM object fully written in VB.NET. I make the
call from VB.NET to the object, are you saying there will be no variability?
Why?

Thanks. The code I posted downloads messages, loops through each message
and inserts it into an SQL Server via stored procedures. VB.NET can
establish a native ODBC interface through the .sqlclient driver but CF must
use OLEDB or the generic SQL driver. In the case, should VB.NET always have
the performance advantage for the same code?

CF will never be as optimized to run on a Windows server and interface with
SQL Server as VB.NET will. For this one reason, CF will lag in performance
compared to VB.NET. I will try the CFMX code with cfpop post my results.

Brett

 

[Samuel R. Neff]

CFMX doesn't support OLEDB, it supports JDBC and ODBC via the JDBC
bridge. However, it also supports MSSQL via a native JDBC driver
(pure Java, no intermediary code).

Similarly, .NET supports MSSQL through a native driver without using
either ODBC or OLEDB. You should use the native mssql driver and not
odbc with .NET.

HTH,

Sam

 

[Samuel R. Neff]

While it certainly may be true that a certain operation will run
better in one technology as opposed to another, it will always be true
that a improperly implemented technology wil perform worse than a
proper implementation. Use the right options for the language and
platform you're targeting.

Sam

 

[Brett]

CFMX doesn't support OLEDB, it supports JDBC and ODBC via the JDBC
bridge. However, it also supports MSSQL via a native JDBC driver
(pure Java, no intermediary code).

Isn't this still slower than the .sqlclient driver VB.NET will use, which is
optimized to work with the OS and target database, since all were designed
by the same people? CFMX isn't optimized to this point.

 

[Brett]

While it certainly may be true that a certain operation will run
better in one technology as opposed to another, it will always be true
that a improperly implemented technology wil perform worse than a
proper implementation. Use the right options for the language and
platform you're targeting.

What do you mean to say here? CFMX for Windows is written to run on a
Windows server and work with SQL Server. This means that CFMX has been
implemented properly and the correct options are being used. It doesn't
mean it is the optimal choice among available languages for use with Windows
and SQL Servers. A language that has been implemented properly, configured
and all necessary options chosen as above, may still lag behind another
language (VB.NET) that is simply better optimized under the hood for that
platform.

Thanks,
Brett

 

[Samuel R. Neff]

I was referring to the fact that you're using a 3rd party com object
when a native CFPOP tag already exists. Using a 3rd party Java
library from VB.NET would also produce poor results.

Best regards,

Sam

 

[Lance R.]

I was referring to the fact that you're using a 3rd party com object
when a native CFPOP tag already exists. Using a 3rd party Java
library from VB.NET would also produce poor results.

IP*Works! Comes in many different editions. The Java Edition is pure java.
The .Net Edition is pure C#. The "VB Edition" contains both COM ActiveX
objects as well as .Net assemblies.

Lance Robinson

/n software

 

[Samuel R. Neff]

IP*Works! Comes in many different editions. The Java Edition is pure java.
The .Net Edition is pure C#. The "VB Edition" contains both COM ActiveX
objects as well as .Net assemblies.

Lance Robinson

/n software

Even more reason not to use the COM object in Java code--there's a
pure Java version available!

Thanks for the info.