Outroducing Introducing the CurrentDate class
Always test, never assume. I was so caught up with how cool typing CurrentDate.time looks, I forgot to test the class for performance. Kristopher Schultz pointed out in the comments that instantiating a new Date instance is much faster than any method in the CurrentDate class. Taking it one step further, I tested it for memory and found similar results.
CurrentDate will be removed from DestroyFramework, but it will always have a place in my heart.
[note] I know “outroducing” is not a word, but it damn well should be.
I’m working on a debug package for DestroyFramework and found the need, in my Log class, to retrieve the current timestamp whenever entries are made. I looked through the almost laughably redundant Date class and found no methods for updating the instance to show the current date and time. Since I’m an avid recycler, there was no way I would instantiate a Date instance each call. Immediately, I thought of the getTimer method. Because it tallies the number of milliseconds since the SWF or AIR app starts, I should be able to add that to the Date.milliseconds property to return the current date. It worked!
1 2 3 4 5 | var date:Date = new Date(); // delay a few seconds date.milliseconds += getTimer(); |
Since I can’t assume a CurrentDate method will be called when getTimer() == 0, all I needed to do was include an offsetTimestamp variable that records getTimer when the Date instance is instantiated. I then subtract that variable from getTimer and I have the right number of milliseconds to update the Date instance with.
1 2 3 4 5 6 | var offsetTimestamp:int = getTimer(); var date:Date = new Date(); // delay a few seconds date.milliseconds += getTimer() - offsetTimestamp; |
The class itself is as easy as pie to use. All of the methods are static, so you can simply call CurrentDate.time and it returns the Date.time property for the current time. I included every get and toString method found in Date. I also included two extra methods, antemeridian and postmeridian that indicate whether the current time is AM or PM. Since it can be formatted in different ways, I made the return values boolean.
1 2 3 4 5 6 | CurrentDate.month; // 11 (months start at 0) CurrentDate.date; // 15 CurrentDate.fullYear; // 2009 CurrentDate.toString(); // Tue Dec 15 8:13:08 GMT-0500 2009 CurrentDate.antemeridian; // true CurrentDate.postmeridian; // false |
As always, the source code for the new class can be found on GitHub.
Great job!!! as usual!
Cheers!
setTime works to modify a Date instance. You still need an offset from the epoch. Nice class though!
hey man just wanted to give you props on the way you introduce your classes. its a clean and easy for all levels to understand.
@Corban — Thanks! I’m really addicted to this whole open source thing
I can appreciate your intention and efforts here. But sometimes adhering too strictly to the axiom “avoid creating new objects” can be detrimental. In this case, at least under a common use case I tested, the CurrentDate class actually performs more poorly than actually creating new instances of Date.
Specifically, in one test run, executing the following line of code 100k times took 605 msec:
month = new Date().month;
…while executing this line of code 100k times took more than twice as long, 1430 msec:
month = CurrentDate.month;
As Steve McConnell observes quite astutely in the book Code Complete, “…programmers are notoriously poor at guessing which code really causes problems.” This is something I’ve found to be universally true including for my own programming. It’s something I keep in mind whenever I’m tempted to create an “optimization” without measuring performance both before and after to make sure I’ve actually done good instead of harm.
Cheers!
@Kristopher — Wow… I didn’t see that one coming. And I can’t believe I didn’t test it either. I just ran memory and performance tests and you’re right. The CurrentDate class will forever be known as the shortest-lived class in DestroyFramework.
I do prefer the look of CurrentDate.month vs new Date().month, for what it’s worth.
Disclaimer: I am not a Flash/AS coder:
What if you take the current-date class and make it static so that it is instantiated on run time? at least then you could wrap the functions so you can still have CurrentDate.month vs Date().month without the resource consumption issue? (The reason for this is that you will not have to instantiant a new object every time you run current date, so your overhead gets reduced (altho may be a tad slower then just Date().month as Kristopher used)
Just a thought.
I just relized they are static and im a moron. I wonder flash has such a horrid lag then?
@David — It’s okay. I think we have a case of the Tuesdays.