Reduce size of standalone script

[tsibley]

The current script weighs in at around 7.5MB. 99% of this heft — I measured! — is from Date::Manip.

Date::Manip is used by normalizetime, which seems pretty useful for core. I also have a few local ops which use Date::Manip which I've previously thought might make sense for core: parsedatetime and datetimetoepoch.

This needs some consideration.

[benbernard]

I'm a big fan of Date::Manip being included, sometimes I bring it into xforms... But the size thing is a problem. I've heard some people recommend Date::Calc, but I've had really bad luck with it, even in more controlled situations than recs...

I wouldn't be opposed to having a no-date version and a date-enabled version of recs, if folks want a smaller version, but personally, I think of recs as the tool set that should just work on the data I have, so the date-enabled version should probably be the default. Not sure though... In the end 7.5 MB doesn't seem like a lot, though I guess, are we trying to speed up startup times? If so, maybe separating the flatpacks is the right idea

[tsibley]

Startup times aren't a problem, it was mostly that as I downloaded recs a few times repeatedly recently, I wondered why it was so darn large. 7.5MB is huge compared to the 76kB total without Date::Manip. :-)

Having some sort of pure-Perl datetime handling in the bundled recs is definitely an advantage, and one we want to keep. The "toolset that just works" is a great goal to keep in sight. If that ends up meaning Date::Manip, then so be it! 7.5MB isn't untenable. I don't think we want to head down the different flavor bundles path, which will just muddy and complicate things.

However, I think it's worth taking a look at the other pure-Perl datetime handling libraries out there that we could replace our non-feature-specific usage of Date::Manip with in core recs. The eminent DateTime, for example, is an excellent library and with the right additional plugins is great at parsing too. Time::ParseDate is a decent and very lightweight option; it's what I often use in my ad-hoc xform commands and is rolled into a personal datetimetoepoch command. Time::Piece may be a good fit as well.

This issue is mostly a placeholder for me to go investigate those things, but also to get feedback about what constraints I should be working under (i.e. if replacing Date::Manip is a no-go, then I don't want to bother!).

[benbernard]

yeah, totally, I'm not opposed to replace it at all, I haven't extensively
worked with any of those others... Date::Manip is generally just so good
(except for perf and memory, so really just at parsing weird strings). Let
me get amling to chime in, but as far as I'm concerned if there is a decent
alternative, I'm game

On Tue, Jun 2, 2015 at 2:39 PM Thomas Sibley notifications@github.com
wrote:

Startup times aren't a problem, it was mostly that as I downloaded recs a
few times repeatedly recently, I wondered why it was so darn large. 7.5MB
is huge compared to the 76kB total without Date::Manip. :-)

Having some sort of pure-Perl datetime handling in the bundled recs is
definitely an advantage, and one we want to keep. The "toolset that just
works" is a great goal to keep in sight. If that ends up meaning
Date::Manip, then so be it! 7.5MB isn't untenable. I don't think we want to
head down the different flavor bundles path, which will just muddy and
complicate things.

However, I think it's worth taking a look at the other pure-Perl datetime
handling libraries out there that we could replace our paltry usage of
Date::Manip with in core recs. The eminent DateTime, for example, is an
excellent library and with the right additional plugins is great at parsing
too. Time::ParseDate is a decent and very lightweight option; it's what I
often use in my ad-hoc xform commands and is rolled into a personal
datetimetoepoch command. Time::Piece may be a good fit too.

This issue is mostly a placeholder for me to go investigate those things,
but also to get feedback about what constraints I should be working under
(i.e. if replacing Date::Manip is a no-go, then I don't want to bother!).

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

[tsibley]

Nod. In my experience, Date::Manip produces too many false positives and has poor timezone handling for me to really trust it, so I use other libraries. I definitely understand the appeal of something that Just Works though.

[elindsey]

Out of curiosity, have any suitable Date::Manip alternatives popped up in the past couple of years?

I'm back around to using recs, but the fatpack is fairly hefty - seeing if it's worth poking at this task. 🙂

[tsibley]

@elindsey None that I'm aware of.