note 83964 rejected from function.str-replace by danbrown
| From: | danbrown@php.net | Date: | Sun, 20 Jul 2008 16:13:24 +0000 |
| Subject: | note 83964 rejected from function.str-replace by danbrown | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-142164@lists.php.net to get a copy of this message | ||
Note Submitter: max at bitsonnet dot com
----
In response to jaimthorn's comment on June 20th:
Thanks for pointing out the slow spot, and it's definitely good to have both examples here. Let
me elaborate on the "slowness" a bit.
It's a given that any kind of meta-programming technique (evaluating some code within your
code, like create_function() does) is always slower than traditional approach, especially in the
language which wasn't built with "dynamism" in mind. Just like "foreach"
is slower than "for" -- there's always a choice between maintainability (clarity and
decoupling of code, declarative style) vs. performance optimization (expanding pieces of code into
simpler, faster routines, general redesign, etc.). The latter one basically turns the code into a
mess. The best thing to do is to find a common ground. There's an easy way to get balanced -
avoid premature optimization. Write code for clarity and conciseness, and only optimize certain
parts when they become bottlenecks. IE, if your application only uses interpolation to send out an
occasional e-mail - you are unlikely to ever need to optimize interpolate function, and rather keep
the code clearer. However, if your application goes through millions of records interpolating them,
this difference will be crucial, and a simple code profiling session will point out the bottleneck
for you.
Best regards,
Max.