1. ODBC.ew
Matt,
I'm curious as to why you implemented freeStmt the way you did. As you may
recall, I've had a serious memory leak when using the standard sequence of
prepareSQL, executeSQL, getData, freeStmt. I'm using v. 1.34, and I only
finally noticed that freeStmt does not use the ODBC function. All the calls
to free() are in Euphoria, where the allocation was done in the dll. I've
elected to change my methodology to execDirectODBC; although I won't be able
to test it until later this afternoon.
Just for background - when running the program for 24 hours without
remediation, memory usage is in excess of 800MB. When cleaning up and re-
initializing the ODBC connection once an hour, memory usage runs about 150MB
for 24 hours. When stopping the service and restarting it, memory usage
is 8MB. My goal is to keep the program at a constant rate over a full week,
expected to be in the neighborhood of 30MB.
Any insight would be appreciated.
Michael J. Sabal
2. Re: ODBC.ew
Michael J. Sabal wrote:
>
> Matt,
> I'm curious as to why you implemented freeStmt the way you did. As you may
> recall, I've had a serious memory leak when using the standard sequence of
> prepareSQL, executeSQL, getData, freeStmt. I'm using v. 1.34, and I only
> finally noticed that freeStmt does not use the ODBC function. All the calls
> to free() are in Euphoria, where the allocation was done in the dll. I've
> elected to change my methodology to execDirectODBC; although I won't be able
> to test it until later this afternoon.
>
> Just for background - when running the program for 24 hours without
> remediation, memory usage is in excess of 800MB. When cleaning up and re-
> initializing the ODBC connection once an hour, memory usage runs about 150MB
>
> for 24 hours. When stopping the service and restarting it, memory usage
> is 8MB. My goal is to keep the program at a constant rate over a full week,
> expected to be in the neighborhood of 30MB.
>
> Any insight would be appreciated.
It's been a while since I've looked at this, but I believe that the free()s
in freeStmt() are only meant to free the stuff that I allocated in
createCursor(). The actual ODBC references should be freed by
freeHandleODBC(). Per this link:
http://msdn2.microsoft.com/en-us/library/ms131681.aspx
SQLFreeStmt() isn't supposed to be used any more. Obviously, the docs
didn't keep up with the code. Try switching to freeHandleODBC() and see
if the memory usage is better.
Matt
3. Re: ODBC.ew
Matt Lewis wrote:
>
> Michael J. Sabal wrote:
> >
> > I've
> > elected to change my methodology to execDirectODBC; although I won't be able
> > to test it until later this afternoon.
> >
> Try switching to freeHandleODBC() and see
> if the memory usage is better.
>
> Matt
I haven't had a chance to try adding freeHandleODBC() to my original code,
but switching to execDirectODBC() has resulted in about 75% less code,
faster execution, and overall stable memory usage of 9MB. I'm sure there
are valid reasons for using prepareSQL; but with a high-end database server,
I would have to recommend using execDirectODBC for all queries.
