PERFORMANCE ADD NAMED PARAMETERS

PERFORMANCE ADD NAMED PARAMETERS

Postby erik78 » Tue 06 May 2008 15:40

Hello everybody,

I have a problem with named uniparameters, exactly in performance when add new parameters.

I implemented a simple application that insert a 300 fields in one table with 32 columns. For to do this, I use the UniConnection and UniCommand (ExecuteNonQuery) components of CoreLab.

Firstly I construct all text without parameters (insert into tablex(ID,ID2,NAME...) values (1,2,'aa',...)) and the test is good (1-2 seconds).

Later I use Named Parameters (insert into tablex(...) values (:ID,:ID2,:NAME,...))and the performance loss:

- if I use 1 Parameters the time of execution is 1-2 seconds
- if I use 2 Parameters the time of execution is 3-4 seconds
- if I use 3 Parameters the time of execution is 5-6 seconds
- if I use 4 Parameters the time of execution is 6-7 seconds
- if I use 5 Parameters the time of execution is 8-9 seconds
- if I use 10 Parameters the time of execution is 17-18 seconds
- if I use 32 Parameters (all columns) the time of execution is 1 minute!!

At the same time, another departament do the same test using the DBExpress CoreLab for Delphi and the performance is good (1-2 seconds).

I pass our the function that create and add the named parameters:

public override void SetValueTo(UniParameterCollection pSqlParameters, string pParamName)
{
UniParameter vParameter;

if (!ReferenceEquals(pSqlParameters, null))
{
//check is value is null
if (IsNull)
vParameter = new UniParameter(pParamName, DBNull.Value);
else
{
vParameter = pSqlParameters.Add(pParamName, UniDbType.Int);
vParameter.Value = vValue;
}
pSqlParameters.Add(vParameter);
}
else
throw new Exception("Sql Parameters not assigned");
}
}

if I comment the "pSqlParameters.Add(vParameter);" line, the execution very quick.

Thanks for our attention.
erik78
 
Posts: 23
Joined: Thu 14 Feb 2008 10:11

Postby Alexey.mdr » Wed 07 May 2008 09:32

We have analysed the problem and determined that the situation is quite involved.
We are working on deploying a solution, but please be warned that this will
take some time and plan your development strategy accordingly.
Alexey.mdr
 
Posts: 729
Joined: Thu 13 Dec 2007 10:24

Postby erik78 » Wed 07 May 2008 10:26

Alexey.mdr wrote:We have analysed the problem and determined that the situation is quite involved.
We are working on deploying a solution, but please be warned that this will
take some time and plan your development strategy accordingly.


Hello,

Thank you for yor reply.

Do you have any idea whatsoever of how much time it can take to find the solution?

I need this information to plan my development strategy.
erik78
 
Posts: 23
Joined: Thu 14 Feb 2008 10:11

Postby Alexey.mdr » Wed 07 May 2008 10:37

Hello!

We plan to fix the issue in two weeks term.
Alexey.mdr
 
Posts: 729
Joined: Thu 13 Dec 2007 10:24

Postby erik78 » Fri 23 May 2008 13:03

Alexey.mdr wrote:Hello!

We plan to fix the issue in two weeks term.


Hello to everybody,

When will be the solution published?

Because I'm waiting it more than 2 weeks. I like to have at response at soon as posible for comunicate it to my boss.

Thanks a lot.
erik78
 
Posts: 23
Joined: Thu 14 Feb 2008 10:11

Postby Alexey.mdr » Fri 23 May 2008 14:40

The build is not ready yet.
The bug fixing takes more time than expected.
We plan to issue a new build in 5-7 days.
Thank you for your patience.
Alexey.mdr
 
Posts: 729
Joined: Thu 13 Dec 2007 10:24

Postby Alexey.mdr » Fri 30 May 2008 14:16

The problem is fixed in the new build.

Alexey.
Alexey.mdr
 
Posts: 729
Joined: Thu 13 Dec 2007 10:24


Return to dotConnect Universal