Hello Rick, On Tue, Mar 25, 2003 at 07:51:16AM +1100, Rick Measham wrote: > At 8:46 PM +0100 24/3/03, Martin Hasch wrote: > >Hello Rick, > > > >On Mon, Mar 24, 2003 at 11:19:45AM +1100, Rick Measham wrote: > >> Attached is the first Beta of DateTime::Event::Easter. Play with it. Poke > >> it. If something doesn't work like you expect, or you want it to work > >> differently, let me know. > > > >I appreciate the way your module tries to optimize running > >time by memoizing results of calculations. This, however, > >is a potential memory leak. Only applications asking for > >the same calculations over and over will draw notable benefit > >from it. Therefore, I would rather have the module just do > >the calculations and let the application take care of memoizing > >(if appropriate) elsewhere. > > I added the memoizing when I noticed the same year being calculated > several times. I'm interested in the possible memory leak, could you > explain more how this can happen?
What I meant when I used the term memory leak was actually that a data structure not supposed for outside access can grow beyond any limits if one uses the module a lot. I stumbled over it when I tried to run a test to compare the module's idea of Easter for a number of millenia with that of other similar modules. Once the physical memory of my PC was used up (storing the Easter dates for all those different years in a Perl hash) and it started swapping everything slowed down so much I began to doubt if the program would make it before most of those happy Easter events would have passed in real time. :-) > >In order to simply speed up the process of calculating several > >dates with different constant offsets from one specific Easter > >Sunday it already would help to store the year and Easter > >date of one calculation in the DateTime::Event::Easter object. > >As in that case the memory footprint would be a small constant, > >I would not object. > > The object is currently used to store which offset is being talked > about .. an object is for 'Palm Sunday'. You then pass various dates > and ask for previous/next/closest etc. This offset is already stored > there. I see. That way some global state seems indeed necessary if one request is supposed to take profit from the stored result of some earlier request. But why not twist that a bit and trade objects representing offsets for methods representing offsets (or one method with an offset parameter, along with suitable constants like pentecost => 49), and let an object represent the set of dates that depend on Easter of a certain year, the year being part of its state. Methods like new(year => ...), following(), previous() would still come in handy to initialize or change the state of such an object. -Martin
