By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,943 Members | 1,875 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,943 IT Pros & Developers. It's quick & easy.

VB.NET vs CFMX tick count distribution?

P: n/a
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
Nov 21 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a

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

Sam
On Fri, 31 Dec 2004 06:25:52 -0500, "Brett" <no@spam.net> wrote:
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


Nov 21 '05 #2

P: n/a
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 = "te**@abc.com";
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", "te**@abc.com", "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" <bl****@newsgroup.nospam> wrote in message
news:6i********************************@4ax.com...

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

Sam
On Fri, 31 Dec 2004 06:25:52 -0500, "Brett" <no@spam.net> wrote:
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

Nov 21 '05 #3

P: n/a

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

On Fri, 31 Dec 2004 10:55:22 -0500, "Brett" <no@spam.com> wrote:
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 = "te**@abc.com";
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", "te**@abc.com", "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

Nov 21 '05 #4

P: n/a
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" <bl****@newsgroup.nospam> wrote in message
news:9s********************************@4ax.com...

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

On Fri, 31 Dec 2004 10:55:22 -0500, "Brett" <no@spam.com> wrote:
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 = "te**@abc.com";
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", "te**@abc.com", "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

Nov 21 '05 #5

P: n/a
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


On Fri, 31 Dec 2004 22:28:58 -0500, "Brett" <no@spam.net> wrote:
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

Nov 21 '05 #6

P: n/a
>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" <bl****@newsgroup.nospam> wrote in message
news:6h********************************@4ax.com... 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


On Fri, 31 Dec 2004 22:28:58 -0500, "Brett" <no@spam.net> wrote:
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

Nov 21 '05 #7

P: n/a

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
On Sat, 1 Jan 2005 11:28:32 -0500, "Brett" <no@spam.net> wrote:
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

Nov 21 '05 #8

P: n/a

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
On Sat, 1 Jan 2005 11:28:32 -0500, "Brett" <no@spam.net> wrote:
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


Nov 21 '05 #9

P: n/a

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:kd********************************@4ax.com...

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.

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
On Sat, 1 Jan 2005 11:28:32 -0500, "Brett" <no@spam.net> wrote:
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

Nov 21 '05 #10

P: n/a

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:fl********************************@4ax.com...

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
Nov 21 '05 #11

P: n/a

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
On Sat, 1 Jan 2005 20:23:43 -0500, "Brett" <no@spam.net> wrote:

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:fl********************************@4ax.com.. .

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


Nov 21 '05 #12

P: n/a

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:gk********************************@4ax.com...

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
Nov 21 '05 #13

P: n/a


On Wed, 5 Jan 2005 11:36:10 -0500, "Lance R."
<la****@removeme.nsoftware.com> wrote:

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:gk********************************@4ax.com.. .

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


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

Thanks for the info.

Nov 21 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.