While optimizing performance forberdir noted that date formatting performance is slow due to DrupalDateTime objects being created:
Many calls like this one: format_date($comment->created->value->getTimestamp()). We already discussed this before, but what happened in the meantime is that format_date() was converted to using DrupalDateTime, so it does internally a new DrupalDateTime($timestamp)->format() (conceptually). Which means we convert from DateTime to timestamp and then back into a DrupalDateTime object. Not necessarly here, but we really should change our TypeData Date class to *somehow* use DrupalDateTime() (extend or wrap, not sure) and avoid this.
Right now the TypedData date class already is a DrupalDateTime instance. I noted that creating this DrupalDateTime instances slowed down things, so I tried going with DateTime instead, giving that results:
before: 248ms for 996 calls
after: 31ms for 996 calls
Then, I reverted this and tried avoiding format_date() in favour of leveraging the already existing object, i.e. use
$comment->created->value->format(variable_get('date_format_medium', 'D, m/d/Y - H:i'));.
before: 441ms Date formatting with date_format()
after: 198ms (996 calls)
So the latter gives a slightly better performance boost + keeps using the DrupalDateTime class. So maybe we can
- Optimize DrupalDateTime object creation - it seems to add quite some weight.
- Have a format() method that accepts Drupal formats as format_date(), such that re-using the object works in a sane way. Imho we could even remove format_date() in favour of $date->format().
|PASSED: [[SimpleTest]]: [MySQL] 58,105 pass(es).|
|PASSED: [[SimpleTest]]: [MySQL] 57,628 pass(es).|
|FAILED: [[SimpleTest]]: [MySQL] 57,892 pass(es), 0 fail(s), and 2 exception(s).|
|FAILED: [[SimpleTest]]: [MySQL] 57,820 pass(es), 2 fail(s), and 2 exception(s).|