Aside from anything else, the function call and object instantiation overhead of this library is insane.

The string comparison function provided as an example is 4 times slower than the code it's based upon, and 3 times slower than a completely equivalent multibyte-aware version.

Libraries like this are bound to introduce overhead, but in the javascript world you don't hear many people complain about the overhead of jQuery, and it is there. I think for most people a string comparison 4 times slower won't mean much. That's not to say it's "okay" to be slow, just saying it may not be big for those not pushing PHP to its boundaries. In fact last time I checked Symfony and Zend had a tremendous impact in terms of overhead, but you (almost) never hear negative comments on them. Heck, even something OOP is slower than the same thing written in procedural style in PHP.

The example I'm talking about is the first non-trivial example in the readme - 34 lines of believable code, not an individual function of the library.

The library is used about once every 3.5 lines, which feels less dense than most jQuery code I see, but that whole function runs 3 times slower than the plain MB-aware equivalent.

Some of the library functions might be implemented inefficiently but from a quick glance they're nearly all very thin wrappers.

Overhead from libraries like Symfony and ZF is quite acceptable since they offer much higher level features which you'd have to code yourself otherwise.

However making all your code (excluding I/O) run up to 3 times slower, just to add some syntactic sugar, is insane.

What causes the overhead? Is there a way to get the sugar without the calories?

A trivial example:

  $len = mb_strlen("wtf");
    # call function mb_strlen

  $len = s("wtf")->len();
    # call function s
      # allocate string object
      # instantiate string object
      # call string ctor
        # set property
    # call method len
        # get property
      # call function mb_strlen
    # destroy object
There's no way to use a syntax like this without either massive overhead, or massive changes in the engine.

There is a somewhat similar experimental project - https://github.com/nikic/scalar_objects - but that's not meant for real world use either.

Personally I think the language, despite its flaws, does its job fine. I don't think it needs turning into Javascript-with-sigils.