Paul M. Jones

Don't listen to the crowd, they say "jump."

Benchmarking call_user_func_array()

Andreas Korthaus wrote the Savant mailing list recently with some interesting benchmark numbers on Savant3 and the output escaping routines. He wrote up a quick template script (in PHP of course) and used the Savant eprint() method 300+ times to escape output (which itself uses only htmlspecialchars() by default). Then he ran the script; the time to run was ...

Result: 161 ms

...

After that I looked at the cachegrind listings to find out
where some noticable time is lost. Looks like escaping costs a
lot of time, so I changed my templates not to use output
escaping:

Result: 12 ms!!!

No, I did not forget a digit ;-)

...

So it seems the way escaping is implemented, hurts performance
very much!

That very dramatic difference in running times (14x!) looked mostly due to the fact that he wasn't using htmlspecialchars() on the echoed output. Then he changed all the "echo" to "echo htmlspecialchars()" and claimed only a 1.5ms difference. Followup emails from his continued benchmarking noted the slow-points in Savant were related primarily to call_user_func_array() calling the escaping functions, although the output escaping itself also adds running time.

All this piqued my interest to see the speed difference between using native functions, user-defined functions, objects, variable-functions, and the call_user_func[_array]() functions. For an experiment, I wrote a user-defined function ...

// mimics htmlentities() as a user-defined function
function html($value)
{
	return htmlentities($value);
}

... and a user-defined class:

class example {
	// mimics htmlentites() as a method
	function html($value)
	{
		return htmlentities($value);
	}
}

Then I wrote a script to make 100,000 calls to each of these:

  • htmlentities($value)
  • html($value)
  • $func($value) where $func = 'html'
  • $object->html($value) where $object = new example()
  • $object->$func($value)
  • call_user_func($func, $value)
  • call_user_func(array($object, $func), $value)
  • call_user_func_array($func, array($value))
  • call_user_func_array(array($object, $func), array($value))

One set of representative results from my Mac Mini (PHP 5.1rc1), in seconds:

name            : diff     : description
native          : 0.614219 : htmlentities($value)
literal_func    : 0.745537 : html($value)
variable_func   : 0.826048 : $func($value)
literal_method  : 0.957708 : $object->html($value)
variable_method : 0.840837 : $object->$func($value)
call_func       : 1.006599 : call_user_func($func, $value)
call_object     : 1.193323 : call_user_func((array($object, $func), $value)
cufa_func       : 1.232891 : call_user_func_array($func, array($value))
cufa_object     : 1.309725 : call_user_func_array((array($object, $func), array($value)

Here's another one:

name            : diff     : total
native          : 0.772733 : 0.772733
literal_func    : 0.737210 : 1.509943
variable_func   : 0.807990 : 2.317933
literal_method  : 0.820931 : 3.138864
variable_method : 0.821516 : 3.960380
call_func       : 1.006845 : 4.967225
call_object     : 1.210223 : 6.177448
cufa_func       : 1.114493 : 7.291941
cufa_object     : 1.307970 : 8.599911

And another, just for good measure:

name            : diff     : total
native          : 0.613295 : 0.613295
literal_func    : 0.733299 : 1.346594
variable_func   : 0.815782 : 2.162376
literal_method  : 0.965143 : 3.127519
variable_method : 0.842771 : 3.970290
call_func       : 1.023640 : 4.993930
call_object     : 1.221747 : 6.215677
cufa_func       : 1.104610 : 7.320287
cufa_object     : 1.449468 : 8.769755

So native calls to htmlentities() are twice as fast as doing effectively the same thing via call_user_func() with an object method, and using call_user_func_array() is 10-20% slower than using call_user_func(). I hadn't realized the differences in speed of execution would be so distinct; of course, I never really thought about it before, either. Clearly PHP has to do a lot more work behind the scenes to map the variables to objects and parameters when using call_user_func_array().

You can download the very simple func_speed.php script here.

Um, you'll need Solar for it (sorry about that, I used the debug-timer object for the testing).


Stumping for Solar

Joe Stump writes a good MVC overview at OnLamp.com in this article. He's kind enough to mention my Solar project in one of the opening paragraphs:

As of this writing, there are very few true MVC frameworks written in PHP. In fact, there is only one that I know of, Solar, that is entirely pure PHP 5 code. Another one out there is Cake, which is trying to be the "Ruby on Rails of PHP." I, personally, have a few problems with both of these frameworks. Both Solar and Cake fail to leverage existing code in PEAR, Smarty, etc. Cake appears a bit disorganized at the moment. Finally, Solar is the work of mostly a single person (not that Paul isn't a great coder or person, but there is only a single gatekeeper at the time of this writing). These may not be issues that concern you, and if they don't concern you, by all means check these two out.

I'm thankful for the mention, but I want to nitpick a bit. ;-)

That Solar does not use PEAR: Solar does not use PEAR code, because most PEAR code (especially for the parts that Solar needs) are not E_STRICT compliant for PHP5. Because Solar aims for strict PHP5, reuse is not really an option.

Regarding Smarty reuse: Solar uses the Savant3 template system instead of Smarty. Of course, I wrote Savant too, so this may not count so much in Joe's eyes. ;-)

That Solar is the work of one person: Well, this part is true in the way he means it; I'm the founder, and pretty much the only author on the project (see below for caveats). I take a lot of direction and input from Solar users and commenters, but only insofar as their opinions match the foundational concepts of Solar to begin with.

The benefit of the "one person" model, at least in the beginning, is that the project has evidence of conceptual integrity (as outlined by Fred Brooks in The Mythical Man Month).

The drawback is that one person can only do so much work over time. If other people want to help, I'm all for it. However, my experience has been that it takes people a long time to contribute new features to a project, usually (1) after they have used and picked it apart over an extended period, and (2) when it has solved other problems for them, but fails to solve an additional related problem. (Bug reports are a different beast. ;-)

Solar, as a public project, has only been around since February 2005. Six months of an in-development project is not really long enough for major contributions to arrive en masse (9 to 12 is usually more like it). I'm very happy for the help I have received so far, though:

  • Clay hosts the site and acts as sounding board
  • Matthew authored Solar_Filter and Solar_Form_Load_Xml
  • Jean-Eric is the first translation contributor
  • Travis as the "loyal opposition" to simplicity and brevity ;-)
  • Everyone else on mailing list :-)

[UPDATE] When I say above that Solar doesn't reuse PEAR code, I mean the libraries. Solar is installed and upgraded using the PEAR installer, and is distributed via a PEAR channel. The entire PHP world has Greg Beaver to thank for recent and spectacular developments on that front. :-)


Savant3 version 3.0.0 beta 2

On the heels of yesterday's Savant2 release, I have a Savant3 beta 2 release today; you can view the change log on the main page. With any luck, this will be the last beta release of Savant3; if I get no bug reports, I'll mark it stable (at last!).

In addition, I've been working on the newly separated Form plugin package; look for a release of that in the next few days, with .phpt-based unit tests included.

And then I get to start documentation on everything. :-)


Savant2 version 2.4.1

This is a minor bugfix release (I was using func_get_args() as a function parameter in one place). Also, I've added a new method "eprint()" as an alternative to "_()" for escaping and printing. You can see the change notes and the download and installation pages for more information.


Interview Errata

I wrote previously that Marcus Whitney had interviewed me for Pro-PHP podcast; well, it is online at last! :-) Thanks again, Marcus, for the opportunity, and don't worry about that high-pitched whine -- I guess that from me talking so fast the whole time (I had no idea I did so). It was a great experience for me. :-)

I misspoke a couple of times, and I want to correct those statements here, as well as provide links to some people, projects, and sources I mentioned.

Regarding the PEAR proposal for Savant, I said it ended up at -3; in fact, it ended at +2 (but needed a +5). You can read many of the comments here, but there are a lot more in the PEAR-DEV mailing list archives in several different threads.

I mentioned Matthew Weier O'Phinney near the end, around the discussion of Solar collaboration; he runs the PHP-based Cgiapp project. Also regarding Solar, I failed to mention Clay Loveless, who has provided hosting, services, and moral support for Solar.

I think that's it; if anyone else notices inaccuracies, or just has questions in general, leave them in the comments here or at Pro-PHP and I'll do my best to answer them. :-)



Solar 0.7.0-devel released

After too-long a hiatus, I've released Solar 0.7.0; you can get it from our PEAR channel server here. (Solar is a simple object library and application repository for PHP5; it is similar to PEAR and Horde, and might be described as a library-like framework for MVC development.)

The interim was filled with lots of improvements, not the least of which are some new classes and fixes from Matthew Weier O'Phinney. His work on the forms portions has been helpful and enlightening; I think we may now have a true MVC contender against HTML_QuickForm when combined with the improved form plugin for Savant3.

The change notes are quite long; you can read them below.

* WARNING: This is a public development release, and is not yet stable.

* Added new class, Solar_Filter, to filter data.  This is a companion to
Solar_Valid and is currently used mostly for prefiltering submitted form
values.  Thanks, Matthew Weier O'Phinney.

* Added new class, Solar_Form_Loader, to allow loading of form elements
from external sources.  Currently has only one method, fromXml(), to load
elements from a SimpleXML file.  Thanks, Matthew Weier O'Phinney.

* Solar:

  * New protected method environment() performs some standardized
  environment setup at Solar::start() time.  Solar now
  automatically...

    * Unsets all registered global variables if 'register_globals'
    is on.

    * Unsets $_REQUEST (you should use Solar::get(), ::post(), and
    ::cookie() for security reasons).

    * Dispels magic quotes from get/post/cookie/files/server
    superglobals if 'magic_quotes_gpc' is on; handles Sybase quotes
    as well as slashed quotes.

    * Turns off 'magic_quotes_runtime' and 'magic_quotes_sybase' so
    that SQL sources do not quote values on retrieval.

  * Solar::start() no longer sets error_reporting and display_errors.
   Per note from Matthew Weier O'Phinney.

  * Fixed bug where start() was calling __solar('start') instead of
  solar('start') on shared objects (the latter is correct).

  * Added locale strings for 'VALID_*' keys to support default
  validation messages in Solar_Sql and Solar_Form.

  * You can now specify an alternate config sources as the only
  parameter to calling Solar::start().  Pass an array to populate
  $config directly, an object to populate from the object properties,
  or a string to indicate an arbitrary path to a config file.  The
  default remains to load $config from the file defined by the
  SOLAR_CONFIG_PATH constant.  Per discussion with Matthew Weier
  O'Phinney.

* Solar_App_*:

  * View scripts now use the new Savant3 auto-escaping function
  and the new Solar_Template plugin locale() for localized strings.

* Solar_Base:

  * Constructor now allows passing of a string as the $config value,
  which is subsequently treated as a path to a php-array config file
  (this means you can have a config file specifically for a class
  instead of having to pass an array).

* Solar_Filter:

  * The alphanumeric() method is deprecated; use alnum() instead, it's
  easier to type. The alphanumeric() method will be removed after the
  0.7.0 release.

* Solar_Form:

  * BC BREAK:  Made $config protected like every other Solar class.
  Config values are now populated through to the new $attribs
  property, which stores attributes for the form tag itself.  If you
  were using $config to retrive form-tag attributes, you should now
  use $attribs instead.  Updated Solar_App_* views to reflect this
  change.

  * Added prefiltering of submitted values; use addFilter() method, or
  add a 'filter' key to the element array when using setElement().
  Thanks, Matthew Weier O'Phinney.

  * The populate() and validate() methods now take an optional
  paramter; if that param is an array, it is used for the $submitted
  property.  This allows you to pick the value population source
  instead of having to choose only from $_GET and $_POST.  Thanks,
  Matthew Weier O'Phinney.

  * Added reset() method to restore form to its originally-configured
  state.

  * Added load() method to load attributes and elements (with filters

  and validations) from an external source.  Per discussions with
  Matthew Weier O'Phinney.

  * When no message is given for validation, attempt to get a default
  validation message from Solar/Locale/en_US.php based on the method
  used for validation (c.f. the new VALID_* translation keys).

* Solar_Sql:

  * In quote(), changed is_double() to is_float() to match with column
  pseudo-type name.

* Solar_Super:

  * No longer uses the magicStripSlashes() filter when values are
  fetched, because the Solar environment setup now takes care of
  slashes at start() time.

* Solar_Template:

  * Updated to Savant3 alpha2 and converted all Solar_App_* view
  scripts to use its new auto-escaping functions. See change notes at
  http://phpsavant.com/yawiki/index.php?area=Savant3.  Of note, the
  'form' plugin will change in the next release, and the 'scrub'
  plugin will disappear in the next release.

  * Added new 'Plugin/' directory with new 'locale' plugin to help
  with locale transalations (you can now use $this->locale('KEY')
  instead of Solar::locale('Solar', 'KEY')).  All Solar_App_* view
  scripts now use this plugin.

  * Adds the 'Solar/Template/Plugin/' directory to the top of the
  configured resource_path automatically.

* Solar_Valid:

  * The alphanumeric() method is deprecated; use alnum() instead, it's
  easier to type. The alphanumeric() method will be removed after the
  0.7.0 release.

Harry Potter III: The Prisoner of Azkaban

What a wonderful series. I've said it before, but I'll say it again: if this is what kids are clamoring to read, then I have hope for the future. Not only are the morals good, but the storylines are preparing the readers for other literary works, including not only Greek and Roman mythology, but also such things as C. S. Lewis' "Narnia" and Tolkien's "Lord of the Rings."

Near the end of the third Potter book, Dumbledore (so much more than just an "old-man-as-mentor" archetype described by Jospeh Campbell) counsels Harry after Harry has mercifully spared a traitorous informer against the Potter family: "This is magic at its deepest, its most impenetrable, Harry. But trust me ... the time may come when you will be very glad you saved [his] life." Anyone who reads that, who has also read the Lord of the Rings, will recognize immediately the similarities to the conversation between Gandalf and Frodo at the door to Moria about Gollum. Kids who read Harry Potter are thus ready to be introduced to Lord of the Rings, and will recognize the motif in the same way.

The Potter books are simply stunning; I can't believe I waited this long to read them. The movies don't do them justice by half.

Incidentally, I have a guess about the Harry/Hermione relationship; I think it will mirror the Luke/Leia relationship. But who knows? ;-)


Savant3 alpha2 Released

Savant3 is a PHP5 E_STRICT compliant template system; it is non-compiling by default, which means it uses plain PHP for its template language. It supports object-oriented plugins and output filters, supports multiple paths for template sources so you can "theme" or "skin" your application, has built-in support for streams as template sources, and has an automated hook for custom user-defined compilers.

The change notes for this release (3.0.0alpha2) are:

  • This is an ALPHA release; while mostly stable, future releases may break backwards comptability.
  • Added methods for escaping output (and for printing of escaped output). As a result, the 'scrub' plugin is deprecated and will be removed from future versions of Savant. Use $this->escape() instead of $this->scrub(), and "$this->_()" instead of "echo $this->scrub()".
  • Added new plugin 'html_attribs' to standardize how HTML attributes are added to a tag.
  • Added a whole series of 'form_*' plugins, one for each element type (button, checkbox, radio, select, text, and so on). These plugins generate only the related element with no layout, and have a standard argument order (name, value, attribs). In addition, they are Solar_Form friendly; if the first argument is an array instead of a string, that array is assumed to be a Solar_Form element array with 'name', 'value', 'attribs', etc. keys. Having them as separate plugins will make it easier to add new form elements, e.g. 'form_date' and 'form_time' pseudo-elements, a la HTML_QuickForm.
  • Added new 'form2' plugin that uses the 'form_*' plugins instead of embedded methods for generating elements. It mimics the current Savant2-derived 'form' plugin and is almost identical in function.
  • With respect to the new 'form_*' and 'form2' plugins, this will be the last release with the current Savant2-derived form plugin. The new 'form2' plugin, and the 'form_*' plugins, will be separated into their own Savant3_Plugin_Form package so they can be upgraded and maintained separately from the core Savant3 distribution.

YaWiki 0.22 released

YaWiki is "yet another wiki" for PHP. While YaWiki was originally designed for collaborative documentation efforts, it also serves nicely as site framework and content management system; sites such as Yawp and Solar use YaWiki and a custom theme.

The change notes for this release of YaWiki are:

  • Schema Change: Added a column to the "yacs" table ("yet another comment system" ;-). Run the "docs/MIGRATE_021_022" SQL code against your database, otherwise comments won't post properly.
  • Now requires Savant 2.4.0, as the default theme templates make extensive use of Savant2::_() to help automate output escaping.
  • Fixed bug in search template noted by David Coallier and reported by Davey Shafik. Thanks, guys.
  • Comment submission now redirects to the same page as the comment was posted on; previously, overzealous application of htmlspecialchars() interfered with proper redirection, sending the commenter to the HomePage for the area.
  • Comment submission now captures the commenter's IP number.
  • Comments are now deletable by the page administrator, not just the area administrator.

When Marcus Whitney interviewed me last week for Pro-PHP (hey Marcus, when's that one coming online?) he asked about some YaWiki technical highlights. I gave perhaps too quick an answer; here's a more-full one from the YaWiki site itself:

  • Uses the Yawp foundation for PHP applications.
  • Built from PEAR and PEAR-compliant objects such as...
  • Database abstracted with DB_Table; works on most anything from MySQL to Oracle, and self-installs the database tables
  • RSS feeds for page content changes (all pages in all areas, all pages in one area, or one page in one area)
  • Has a special AreaMap page that lets you define a page hierarchy for navigation elements
  • Supports separate name spaces (called "areas") in one installation
  • Supports anonymous users and user authentication
  • An access control list that lets the wiki administrator control who can edit and view individual pages in each area
  • A comment system for users who are not allowed to edit pages directly
  • Theme-aware (build your own look and feel) using the Savant template system