possible memory leak in quantlib addin

[P Nelnik]

Good morning all,

Recently I was looking at the results in the Option.xls sheet that comes with the quantlib xll installation.
By default it is located:  C:\Program Files\QuantLibXL\Workbooks\StandaloneExamples\Option.xls

If I recalc the sheet a few times I see that handles change for example european_option#3706 becomes european_option#3707
which is all fine. However I noticed that I then type european_option#3706 into a cell, I would expect that the handle would be no longer valid and so I would expect not to be able to use it again. But to my surprise the handle still worked.
This to me looked like a possible memory leak. I.e. old handles are not being deleted.

To test it, I wrote the following VBA:
Option Explicit

Sub calc_forever()
    ' This can be used to check for the presence of memory leaks.
    ' The sheet is recalculated multiple times, if there is a memory leak,
    ' then the process size will grow.
    '
    ' To terminate type: Ctrl+Break
    While True
        Application.CalculateFull
    Wend
   
End Sub

When I left the sheet recalcing for a while (20min) I did indeed see the process size grow steadily, (though not spectacularly).
This is further evidence of the memory leak.

In my experience, when handles in excel are properly implemented, sheets can be left recalculating thousands of times over hours or days and the process size won't grow.

Regards
Philip



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

Hi Philip

you wrote:
> If I recalc the sheet a few times I see that handles change for example
> european_option#3706 becomes european_option#3707
> which is all fine. However I noticed that I then type european_option#3706
> into a cell, I would expect that the handle would be no longer valid and so
> I would expect not to be able to use it again. But to my surprise the handle
> still worked.

the ObjectID's #xxxx suffix is not really part of the object ID name,
it's just an informative counter to help detect how many times an
object is created in a workbook; it's there mainly to help avoid
useless constructions.
To prove it see the attached spreadsheet Book0.xls where a TestQuote
can be created multiple times using the F9 key:  the same (randomized
and changing) value is returned by accessing the quote with whatever
#xxxx suffix.

> This to me looked like a possible memory leak. I.e. old handles are not
> being deleted.

they are deleted. Objects are created as shared_ptr, so as long as
nobody is pointing to them they are destructed.

> To test it, I wrote the following VBA:
> Option Explicit
>
> Sub calc_forever()
>     ' This can be used to check for the presence of memory leaks.
>     ' The sheet is recalculated multiple times, if there is a memory leak,
>     ' then the process size will grow.
> [...]
>    While True
>        Application.CalculateFull
>   Wend
> [...]
> In my experience, when handles in excel are properly implemented, sheets can
> be left recalculating thousands of times over hours or days and the process
> size won't grow.

you can check that using with Book1.xls the memory usage is stable.

So you're now probably wondering what the attached Book2.xls if for.
Well your email ringed a familiar bell, as I've got suspicious about
the memory usage of my QuantLib Excel sessions.
So I tried something more than what you reported and noticed that as
soon as RelinkableHandle come into play there is really a leak, as you
can see using Book2.xls
The leak is the RelinkableHandle construction, and in fact can be
avoided using Application.Calculate instead of
Application.CalculateFull

I hope Eric will step in here :-)

ciao -- Nando

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users