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 <[EMAIL PROTECTED]> 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 --
pgpivzyAm7UOQ.pgp
Description: PGP signature