Thread: Deallocation speed

Deallocation speed

From
Mark Simonetti
Date:
Hi,
I'm currently working on a c++ project that uses the psqlodbc driver.

I have a query that returns over 26000 rows, and about 45 columns.

When it comes to closing the statement using SQLFreeStmt(hstmt,
SQL_CLOSE), the command seems to take about 70 seconds to return (on a
3.16ghz processor!).   This just doesn't seem right.  Is there something
I may be missing?

I thought I'd ask first before I posted more details incase it is
something obvious.

Thanks,

Mark.


Re: Deallocation speed

From
Hiroshi Inoue
Date:
Mark Simonetti wrote:
> Hi,
> I'm currently working on a c++ project that uses the psqlodbc driver.
>
> I have a query that returns over 26000 rows, and about 45 columns.
>
> When it comes to closing the statement using SQLFreeStmt(hstmt,
> SQL_CLOSE), the command seems to take about 70 seconds to return (on a
> 3.16ghz processor!).   This just doesn't seem right.  Is there something
> I may be missing?

Aren't you turning on the mylog option?

regards,
Hiroshi Inoue

Re: Deallocation speed

From
Mark Simonetti
Date:
On 13/04/2010 14:03, Hiroshi Inoue wrote:
> Mark Simonetti wrote:
>> Hi,
>> I'm currently working on a c++ project that uses the psqlodbc driver.
>>
>> I have a query that returns over 26000 rows, and about 45 columns.
>>
>> When it comes to closing the statement using SQLFreeStmt(hstmt,
>> SQL_CLOSE), the command seems to take about 70 seconds to return (on
>> a 3.16ghz processor!).   This just doesn't seem right.  Is there
>> something I may be missing?
>
> Aren't you turning on the mylog option?
>
> regards,
> Hiroshi Inoue
>
>

No, the log is not turned on.  I turned it on temporarily to see if it
contained any useful information regarding the problem.

Interestingly, if I do not run the program from the Visual Studio IDE,
the problem goes away.  The problem only seems to exist if I run the
program in the Visual Studio IDE in either Debug or Release mode.

If I enable UseDeclareFetch in the psqlODBC connection string the
problem also goes away, indicating it is indeed a something that occurs
while psqlODBC is freeing up memory from a large set of data - so maybe
it is Visual Studio is hooking into the memory allocation/deallocation
of the psqlODBC?

I can now at least work round the problem while using the IDE, and not
worry at all about the problem in production as it does not then occur.

I'm still surprised it happens though!

Mark.