Using ADO 2.6 with Visual Baisc 6.0 is more efficient than Visual C++ 6.0? 
Author Message
 Using ADO 2.6 with Visual Baisc 6.0 is more efficient than Visual C++ 6.0?

The same code I write with VB6.0 often faster 7-8% than that with VC6.0
   :s  Why?


Sun, 31 Oct 2004 16:00:22 GMT  
 Using ADO 2.6 with Visual Baisc 6.0 is more efficient than Visual C++ 6.0?
gohst

It could be because you are a much better VB programmer than a VC++
programmer.

With specific code to analyze, it is near impossible to tell.

best regards
roy fine


Quote:
> The same code I write with VB6.0 often faster 7-8% than that with VC6.0
>    :s  Why?



Sun, 31 Oct 2004 20:51:52 GMT  
 Using ADO 2.6 with Visual Baisc 6.0 is more efficient than Visual C++ 6.0?
A few days ago one guy of our team mentioned in this newsgroup that a COM+
component written with VC using ADO 2.6 is slower than one written with VB,
but he had not specified the situation. Now I'll show more detail. Sorry
about my poor English first :).

First we created a VB ActiveX DLL project and added a class and added a
method like:

Public Sub ExecuteSQLCommand(sql As String)
    Dim cn As ADODB.Connection
    Set cn = New Connection
    cn.Open ConnectionString
    cn.Execute sql
    cn.Close
    Set cn = Nothing
End Sub

And then we created a VC project with ATL COM AppWizard, added an ATL Object
and added a method like:

BOOL CMLDBL::Commands(_bstr_t sql)
{
 _CommandPtr pCom;
 try
 {
  pConn.CreateInstance( __uuidof(Connection));
  pConn->Open(mConnectionString,"","",-1);
  pCom->Execute(sql,NULL,adCmdText);
  pConn->Close();
  pConn=NULL;
 }
 catch(_com_error * e)
 {
  char* Error = (char*)e->ErrorMessage();
  WriteLog(Error);
  return false;
 }
 return true;

Quote:
}

Both projects were compiled and added into the COM+ Service as a library
application.
We wrote a program to create an instance, run the method, and then release
the instance 400 times for each components, and then found out the VB one is
faster than the VC one about 2%.

All of us believe VC must faster than VB, for finding out the problem, we
changed the code like:

VB:
Public Sub ExecuteSQLCommand(sql As String)
    Dim cn As ADODB.Connection
    Set cn = New Connection
    Set cn = Nothing
End Sub

VC:
BOOL CMLDBL::Commands(_bstr_t sql)
{
 _CommandPtr pCom;
 try
 {
  pConn.CreateInstance( __uuidof(Connection));
  pConn=NULL;
 }
 catch(_com_error * e)
 {
  char* Error = (char*)e->ErrorMessage();
  WriteLog(Error);
  return false;
 }
 return true;

Quote:
}

Yes, just create a ADO connection instance but don't make connection to a
database and don't execute any SQL command. This time, the VC component was
faster than the VB one about 15%.

At last, we changed the code again:

VB:
Public Sub ExecuteSQLCommand(sql As String)
End Sub

VC:
BOOL CMLDBL::Commands(_bstr_t sql)
{
 return true;

Quote:
}

Yah, nothing they do. The VC one faster than the VB one about 30%!

So we think that we used a wrong / or an inefficient code to use ADO in the
VC project, but all articles about using ADO in VC commend the code we
wrote. What's wrong? Can somebody give us any idea? thanks.

best regards
qmigh



Tue, 02 Nov 2004 14:25:24 GMT  
 Using ADO 2.6 with Visual Baisc 6.0 is more efficient than Visual C++ 6.0?
How about using BSTR instead of _bstr_t? Also, you can use
    pCom->Execute(sql,NULL,adExecuteNoRecords);
instead of:
    pCom->Execute(sql,NULL,adCmdText);

This is because your method is not returning a recordset(its another story
if it is).

Furthermore, you should make a few run first prior to testing as the initial
connection to the Database will always be slower that the subsequent ones
because of Connection pooling implemented by ADO. Talking about pooling,
since you are hosting your component under COM+, you could implement Object
Pooling which you can only do with MTA (can't do that in VB). When you've
done this, you can see more of the difference.

HTH

Lito


Quote:
> A few days ago one guy of our team mentioned in this newsgroup that a COM+
> component written with VC using ADO 2.6 is slower than one written with
VB,
> but he had not specified the situation. Now I'll show more detail. Sorry
> about my poor English first :).

> First we created a VB ActiveX DLL project and added a class and added a
> method like:

> Public Sub ExecuteSQLCommand(sql As String)
>     Dim cn As ADODB.Connection
>     Set cn = New Connection
>     cn.Open ConnectionString
>     cn.Execute sql
>     cn.Close
>     Set cn = Nothing
> End Sub

> And then we created a VC project with ATL COM AppWizard, added an ATL
Object
> and added a method like:

> BOOL CMLDBL::Commands(_bstr_t sql)
> {
>  _CommandPtr pCom;
>  try
>  {
>   pConn.CreateInstance( __uuidof(Connection));
>   pConn->Open(mConnectionString,"","",-1);
>   pCom->Execute(sql,NULL,adCmdText);
>   pConn->Close();
>   pConn=NULL;
>  }
>  catch(_com_error * e)
>  {
>   char* Error = (char*)e->ErrorMessage();
>   WriteLog(Error);
>   return false;
>  }
>  return true;
> }

> Both projects were compiled and added into the COM+ Service as a library
> application.
> We wrote a program to create an instance, run the method, and then release
> the instance 400 times for each components, and then found out the VB one
is
> faster than the VC one about 2%.

> All of us believe VC must faster than VB, for finding out the problem, we
> changed the code like:

> VB:
> Public Sub ExecuteSQLCommand(sql As String)
>     Dim cn As ADODB.Connection
>     Set cn = New Connection
>     Set cn = Nothing
> End Sub

> VC:
> BOOL CMLDBL::Commands(_bstr_t sql)
> {
>  _CommandPtr pCom;
>  try
>  {
>   pConn.CreateInstance( __uuidof(Connection));
>   pConn=NULL;
>  }
>  catch(_com_error * e)
>  {
>   char* Error = (char*)e->ErrorMessage();
>   WriteLog(Error);
>   return false;
>  }
>  return true;
> }

> Yes, just create a ADO connection instance but don't make connection to a
> database and don't execute any SQL command. This time, the VC component
was
> faster than the VB one about 15%.

> At last, we changed the code again:

> VB:
> Public Sub ExecuteSQLCommand(sql As String)
> End Sub

> VC:
> BOOL CMLDBL::Commands(_bstr_t sql)
> {
>  return true;
> }

> Yah, nothing they do. The VC one faster than the VB one about 30%!

> So we think that we used a wrong / or an inefficient code to use ADO in
the
> VC project, but all articles about using ADO in VC commend the code we
> wrote. What's wrong? Can somebody give us any idea? thanks.

> best regards
> qmigh



Tue, 02 Nov 2004 19:49:39 GMT  
 Using ADO 2.6 with Visual Baisc 6.0 is more efficient than Visual C++ 6.0?
Hi,
    If your development is C++, it is much better to directly use OLEDB
instead of ADO. This is especially true if your components are used at the
server side. The direct use of OLEDB avoids lots of ADO side effects, exta
layer, lots of data conversions (VARIANT and BSTR), and others. Keep in mind
that ADO is mainly designed for IIS scripting languanges and simplicity,
which you can see from ADO interfaces and objects archtecture. It is not
engineered for C++ development at all. You can test it with samples from
www.udaparts.com.

--
Yuancai (Charlie) Ye
See 30 real well-tested advanced OLEDB samples
Use of free SocketPro for creating super client and server application with
numerous samples
www.udaparts.com


Quote:
> The same code I write with VB6.0 often faster 7-8% than that with VC6.0
>    :s  Why?



Tue, 02 Nov 2004 21:01:40 GMT  
 Using ADO 2.6 with Visual Baisc 6.0 is more efficient than Visual C++ 6.0?
How about keeping the 'connection' open until finished.  Connection time is
VERY important.

--
Hank Williams
Quantum Technologies, Inc.


| A few days ago one guy of our team mentioned in this newsgroup that a COM+
| component written with VC using ADO 2.6 is slower than one written with
VB,
| but he had not specified the situation. Now I'll show more detail. Sorry
| about my poor English first :).
|
| First we created a VB ActiveX DLL project and added a class and added a
| method like:
|
| Public Sub ExecuteSQLCommand(sql As String)
|     Dim cn As ADODB.Connection
|     Set cn = New Connection
|     cn.Open ConnectionString
|     cn.Execute sql
|     cn.Close
|     Set cn = Nothing
| End Sub
|
| And then we created a VC project with ATL COM AppWizard, added an ATL
Object
| and added a method like:
|
| BOOL CMLDBL::Commands(_bstr_t sql)
| {
|  _CommandPtr pCom;
|  try
|  {
|   pConn.CreateInstance( __uuidof(Connection));
|   pConn->Open(mConnectionString,"","",-1);
|   pCom->Execute(sql,NULL,adCmdText);
|   pConn->Close();
|   pConn=NULL;
|  }
|  catch(_com_error * e)
|  {
|   char* Error = (char*)e->ErrorMessage();
|   WriteLog(Error);
|   return false;
|  }
|  return true;
| }
|
| Both projects were compiled and added into the COM+ Service as a library
| application.
| We wrote a program to create an instance, run the method, and then release
| the instance 400 times for each components, and then found out the VB one
is
| faster than the VC one about 2%.
|
| All of us believe VC must faster than VB, for finding out the problem, we
| changed the code like:
|
| VB:
| Public Sub ExecuteSQLCommand(sql As String)
|     Dim cn As ADODB.Connection
|     Set cn = New Connection
|     Set cn = Nothing
| End Sub
|
| VC:
| BOOL CMLDBL::Commands(_bstr_t sql)
| {
|  _CommandPtr pCom;
|  try
|  {
|   pConn.CreateInstance( __uuidof(Connection));
|   pConn=NULL;
|  }
|  catch(_com_error * e)
|  {
|   char* Error = (char*)e->ErrorMessage();
|   WriteLog(Error);
|   return false;
|  }
|  return true;
| }
|
| Yes, just create a ADO connection instance but don't make connection to a
| database and don't execute any SQL command. This time, the VC component
was
| faster than the VB one about 15%.
|
| At last, we changed the code again:
|
| VB:
| Public Sub ExecuteSQLCommand(sql As String)
| End Sub
|
| VC:
| BOOL CMLDBL::Commands(_bstr_t sql)
| {
|  return true;
| }
|
| Yah, nothing they do. The VC one faster than the VB one about 30%!
|
| So we think that we used a wrong / or an inefficient code to use ADO in
the
| VC project, but all articles about using ADO in VC commend the code we
| wrote. What's wrong? Can somebody give us any idea? thanks.
|
| best regards
| qmigh
|
|



Tue, 02 Nov 2004 22:29:07 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Problem with Visual Studio 6.0 (Visual C++ 6.0) !!!!

2. Using ADO in Visual C++ 6.0

3. Visual C++ .NET reviews, comparisons to Visual C++ 6.0

4. Visual C++ 6.0 vs. Visual C++ .NET

5. Visual C++ 6.0 contra Visual C++ Technology Preview IE4

6. DoModal Visual C++ 6.0 and Visual C++ .NET?

7. Visual C++ 6.0 contra Visual C++ Technology Preview IE4

8. Is there a way to merge visual C++ 6.0 and Embedded visual C++ 4.0

9. |||||||||| ADO : PROBLEM WITH MoveFirst AND EndOfFile under Visual C++ 6.0 |||||||||||

10. porting visual c++ 6.0 addins to visual studio.net

11. Microsoft Visual Studio.NET V.S. Microsoft Visual C++ 6.0

12. Performance Test on Visual C++ 6.0 and Visual C++.NET

 

 
Powered by phpBB® Forum Software