Rasmus Lerdorf's analysis of XHP | Hacker News Reader

Rasmus Lerdorf's analysis of XHP

toys.lerdorf.com

72 pointsmattwdelong20 comments

Heh, now I see why they had to invent HipHop. It's an interesting idea - trade off speed for readability and security, and then write a PHP->C++ compiler to recover the speed you've lost. I wonder whether it would've been easier to use a language + templating system that gets security right in the first place, though.

XHP development started very very recently and had absolutely nothing to do with HipHop.

From those benchmarks though it seems it would only be really effective with HipHop in a high CPU usage environment.

As explained in the comments in the article, it is effective even without HipHop. Rasmus explains that as well in his article.

  return $this->renderBaseAttrs() . ' />';

No wonder it's expensive. If you serialize a tree of objects by concatenating subtrees into substrings, most values are copied many times depending on the depth of the tree, and you end up doing O(n log n) work. But as for the alternative

  there was basic XSS filtering in place for the naked
  $_POST['name'] variable in the plain PHP version

isn't knowing you have to encode some but not all of your output worse than just encoding all of it? This is the kind of design mistake that leads to databases accidentally full of HTML entities. Or more likely, half full.

I see no reason those XHP templates couldn't just be cached as regular old PHP. It's a nice tool to have during development only.

Call me old-fashioned, but I have been weary of source-code transformations since I first touched C++

Unless you code in raw machine code, everything is a source code transformation.

Yes, but going from one HLL to another is much harder than going from a HLL to machine code.

Not that I regard PHP a particularly HL language

Only if you care about the readability and maintainability of the target HLL.

Going from one HLL to another if you never plan to look at or change the generated code is significantly easier than going to machine code. Just look at all the compilers that target C.

APC is doing that, just one step better, by caching them as PHP Opcodes.

He's benchmarking based off of a 10 line PHP program and then extrapolating that this is why HPHP is needed?

It's a joke.

HPHP's 50% speed boost does not make up for a templating engine that 43 times slower.

No, it's stupid because a 10 line program isn't the least bit representative.

Though he points out that if your PHP script spends most of its time doing algorithmic calculations, waiting on I/O, etc., or if you're using an external template library already, then you might well not notice the difference anyway.

It doesn't matter if it isn't the least bit representative.

Being 43 times slower is going to make a noticeable impact on latency especially when the templates are likely to be larger than the example shown.

No, it's completely meaningless unless your programs are only 10 lines long. You have no idea what part of it is slower.

His benchmark is all about the template engine because that's what XHP changes.

The impact of XHP and HPHP depend very much on what you are doing to serve your requests.

The title of the actual page is called "A quick look at XHP"

Well you know what they say about putting lipstick on a pig...

Reply on news.ycombinator.com