In my quest to micro-optimize the speed of my applications, I had found a new culprit: parsing dates. For some of my API request, I use a lot of date parsing to create graphs and statistics. Because most of my applications are made using Laravel, I rely heavily on the now() function, which returns a new Carbon instance.
I really like using Carbon because it gives an object-oriented API to manipulate time. However, I wondered how the performance of this library compares to using native PHP functions, as I am parsing a few hundred dates for some requests.
So, I set up a benchmark. :)
The setup#
The function I used most of all is to find a date that is x days in the past. This can be achieved with the following code:
$date = now()->subDays($x)->format('Y-m-d');
To achieve the same thing in native PHP code, I used the strtotime function that interprets a string and turns it into a timestamp.
$date = date('Y-m-d', strtotime("$x days ago"));
The test#
To test both methods, I set up a simple for loop with an incrementing counter and kept track of how long it took the code to execute. I started with 1 million iterations but lowered this number after the Carbon function was still running after 2 minutes. So, the tests were executed over 25.000 iterations.
To be honest, the results were even better than I expected. The strtotime function beat Carbon with about 60% of its time.
Parsed 25.000 dates in 2.89602 seconds using carbon.
Parsed 25.000 dates in 1.877997 seconds using strtotime.
I wasn't done#
Not long after running the test, I realized that using the strtotime function I parse a string into an integer, and then back into a string. To me, this looks like a lost operation. So, there was yet another option.
What strtotime actually does is take the current timestamp and modify it according to whats in the passed string. I can do this myself as well and it would save PHP the time of parsing the string. So, the next contender for this benchmark was the following function:
$date = date('Y-m-d', time() - ($x * 24 * 60 * 60));
And yes, the results were even better! However slightly less then I expected.
Parsed 25.000 dates in 1.599871 seconds using timestamps.
To conclude#
Yes, native PHP functions are faster in parsing dates compared to an object-oriented library written in PHP. However, keep in mind that we are talking about microseconds for each calculation. So, if you are only performing about 4 complex date manipulations I would recommend staying with Caron. It has a great API and awesome functionalities.
On the other hand for requests that have over 100 datetime manipulations, I will be replacing Carbon objects with their PHP datetime counterparts to improve the performance. In the end, it all depends on finding a balance between easily readable code and having optimal performance. Which is totally up to you.
Data#
For those willing to try the benchmark themselves, I have created a Gist with the source code I used. Keep in mind that you will have to run this code in a Laravel context, or replace the now() functions with Carbon instances.