[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-datetime
Subject:    Re: hires DateTime->from_epoch( epoch => ... ) values
From:       Joshua Hoblitt <jhoblitt () ifa ! hawaii ! edu>
Date:       2005-08-09 20:40:24
Message-ID: 20050809204024.GA15726 () ifa ! hawaii ! edu
[Download RAW message or body]


On Mon, Aug 08, 2005 at 09:02:06AM -1000, Joshua Hoblitt wrote:
> On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote:
> > On Mon, 8 Aug 2005, John Siracusa wrote:
> > 
> > >On 8/8/05, Dave Rolsky <autarch@urth.org> wrote:
> > >>Does anyone object to adding Math::BigFloat as a
> > >>prereq?
> > >
> > >What are the performance/memory implications?  I don't object to the 
> > >prereq,
> > >but I would like to know if we're in for any new speed/bloat issues.  (I
> > >only really care about per-object overhead, not the cost of loading
> > >Math::BigFloat itself.)
> > 
> > If I read the patch directly, we never store the bigfloat object, we just 
> > use it to make sure that nanoseconds has the right value.
> 
> That's correct.  A single Math::BigFloat object is used as an
> intermediate value, to hold the hires epoch 'string', which is then
> immediately discarded after seperating the integer and fractional
> values.
> 
> It shouldn't have much impact on memory unless Math::BigFloat has leaks.
> ;)

On second thought, would we be better off simplifying
DateTime::from_epoch to only handle integer values and move all the
floating point complexity into DateTime::HiRes?  That would be
optimizing the common case.

Cheers,

-J

--

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]