On one hand, I prefer to have a properly formatted code, but on the other,
most systems i have worked with have a very high cost of string
concatenation, and I have a strong suspicion PHP is guilty of that too.
Constructing HTML one element/value at a time might prove to be on of the
bigger perf bottlenecks.
From my personal experience, once I worked on a
networking lib for
proprietary protocol, and noticed that there was a lot of logging
calls in
the form of Log("value1=" + value1 + " value2=" + value2 ...). After
I
switched it to the form "Log("value1={0}, value2={1}", value1, value2),
the
code became an order of magnitude faster because the logging
framework deferred concatenation until the last moment after it knew that
logging is needed, and the actual concatenation was done for the whole
complex string with values, not one substring at a time.
On Mon, May 13, 2013 at 6:10 PM, Antoine Musso <hashar+wmf(a)free.fr> wrote:
Le 13/05/13 19:26, Max Semenik a écrit :
Hi, I've seen recently a lot of code like
this:
$html = Html::openElement( 'div', array( 'class' => 'foo' )
. Html::rawElement( 'p', array(),
Html::element( 'span', array( 'id' => $somePotentiallyUnsafeId
),
$somePotentiallyUnsafeText
)
)
. Html::closeElement( 'div' );
IMO, cruft like this makes things harder to read and adds additional
performance overhead.
Html is just like our Xml class, that let us raise the probability that
the result code will be valid. That is also a good way to make sure the
content is properly escaped, though in the example above that could lead
to some mistake due to all the nested calls.
For the performance overhead, it surely exist but it is most probably
negligible unless the methods are in a heavily used code path.
Ideally we would use templates to generate all of that. That will let us
extract the views logic out of the PHP code.
--
Antoine "hashar" Musso
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l