Thanks for this article - it takes me back. I bought Data Munging with Perl when it came out, and I joined the group with Dave Rolsky and others during the development of DateTime (I watched and kibbitzed). My question for you comes from how I approached using DateTime early on, when it was emphasized that its priority was accuracy and correctness rather than speed. For uses in which quick responsiveness was required, initialization of DateTime seemed to be an issue.
A solution I developed back then was to use DateTime's capabilities to generate a read-only SQLite database with a record for each date in the relevant range for the application. Each date record had fields for a few dozen attributes such as day, week, and month of the year, start and end dates of the date's week & month, day & month names and abbreviations (English in my uses, but localizable), and more. My calendaring apps - which by their nature deal with many dates at a time - could then do quick lookups and date arithmetic, without the overhead of loading DateTime or another similar module. The app using the date db was also provided an api to generate additional date info if needed, only then loading DT.
Today I still maintain production calendaring apps that use this approach. I've encapsulated the db generation and extension api into a simple module, and now I rarely find myself needing to think through how to get a quick date-related result for some use. Of course machines are considerably faster today, and DateTime is more sleek and powerful (although still favoring correctness over speed). So I'm wondering whether pre-calculating date info is still a good approach. To benchmark a real-world comparison would take a big re-factoring of one of my apps to make more direct use of DT, so I haven't done that yet. But I'm thinking about whether the future development path for my apps should entail moving away from the pre-calc approach. Or maybe I should publish my calendar generating module in case it's still a viable way to go.
Any thoughts?
Thanks!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Dave,
Thanks for this article - it takes me back. I bought Data Munging with Perl when it came out, and I joined the group with Dave Rolsky and others during the development of DateTime (I watched and kibbitzed). My question for you comes from how I approached using DateTime early on, when it was emphasized that its priority was accuracy and correctness rather than speed. For uses in which quick responsiveness was required, initialization of DateTime seemed to be an issue.
A solution I developed back then was to use DateTime's capabilities to generate a read-only SQLite database with a record for each date in the relevant range for the application. Each date record had fields for a few dozen attributes such as day, week, and month of the year, start and end dates of the date's week & month, day & month names and abbreviations (English in my uses, but localizable), and more. My calendaring apps - which by their nature deal with many dates at a time - could then do quick lookups and date arithmetic, without the overhead of loading DateTime or another similar module. The app using the date db was also provided an api to generate additional date info if needed, only then loading DT.
Today I still maintain production calendaring apps that use this approach. I've encapsulated the db generation and extension api into a simple module, and now I rarely find myself needing to think through how to get a quick date-related result for some use. Of course machines are considerably faster today, and DateTime is more sleek and powerful (although still favoring correctness over speed). So I'm wondering whether pre-calculating date info is still a good approach. To benchmark a real-world comparison would take a big re-factoring of one of my apps to make more direct use of DT, so I haven't done that yet. But I'm thinking about whether the future development path for my apps should entail moving away from the pre-calc approach. Or maybe I should publish my calendar generating module in case it's still a viable way to go.
Any thoughts?
Thanks!