 Welcome to the final scheduled session of talks, the Open Programming Minicomf. We have two PHP kind of sort of related talks for you now. And after that, we have lightning talks. Once again, if you're interested in presenting one, the link is on the schedule page for today on the LCA website. Our first presenter is an unshaven, unkempt mess with terrible hair, according to his biography, who works in bug triaging on the PHP project. He's going to be telling us all about the state of PHP. Please welcome Adam Harvey. Thank you very much. Can everybody hear me? Yep, cool. So, as Chris said, I'm Adam Harvey. If you are an optimist, you may follow along with the slides. I haven't actually tested them in any browsers that aren't the Chrome install on this computer, so I don't know, they might work. The state of PHP, I'm glad Richard Jones isn't here because I'm ripping off his Python talks. I've had several suggestions today, actually, for what the state of PHP really is. Most of them have involved four-letter words that I can't actually repeat while on camera. But I think the state of PHP isn't so bad in actual fact. So I'm going to talk you through where we are, where we've been to a little, to a small extent, and where we're going. It was an interesting couple of weeks for the PHP project at the start of January because it turns out that there was a magic number that on certain compiles of PHP could in fact make it lock up. How interesting. That, of course, necessitated some rather emergency releases and an awful lot of theories online as to what was the actual cause of it and who was to blame. Well, at the end of the day, we were to blame. I mean, whether it was our code or not, it was a bug in PHP. So, there are three branches that are or have recently been active. We have PHP 5.2, we have PHP 5.3, and we have Trunk, which was PHP 5.3, and got forked back in March so we could do some actual work. So we'll start with the old one, PHP 5.2, which is probably what most of you are still running. So, the most recent release of PHP 5.2 was 5.2.17, was released on January 6th. PHP 5.2 was officially end of life on December 9, 2010. Two releases earlier. Well, yeah. So, 5.2.15, we broke open base door. That was probably a problem. 5.2.16, of course, had that interesting little 32-bit issue, and so we've released 5.2.17. Now, we've been gradually deprecating 5.2 and limiting the support for it for about a year now, and 5.2 is officially end of life, as the last three release announcements have said. So, presumably, we just keep reviving it. It stumbles around like a zombie for a little while, and then we put it back to bed. It's not impossible that there'll be a 5.2.18. The tree's still open. There have actually been a couple of commits since 5.2.17, but I think it's honestly pretty unlikely. So, what does that really mean for you? What it really means is you need to upgrade. 5.2 is dead. Now, of course, it's only really dead from our point of view. Distro packages for distros are still maintaining PHP 5.2 packages within active distros. They're going to keep back porting fixes, so the sky isn't really falling as such. But you probably can anyway, and I think it's time to upgrade. The transition from 5.2 to 5.3 is not terribly frightening. Okay, maybe if you've named methods, namespace, or you've got a code base that was first written for PHP 3, yeah, you might have a couple of issues. But for the most part, migrating is really just a matter of doing the appropriate testing. So, I implore you all, if the only thing I actually say that means anything today is this, please upgrade, or at least start planning to upgrade. Red Hat did us a bit of a favour actually. The Red Hat 5, Red Hat Enterprise Linux 5 still ships PHP 5.1.6 as the standard version. They have now shipped, in the most recent update, which I think was two weeks ago, they have now shipped 5.3 packages called PHP 53. You might want to consider using them. They're into the public service announcement. So, 5.3, the actual current stable branch. Most recent release for the same issue was 5.35, and that was also released on January 6. Now, 5.3 continues to be actively developed. It is, to repeat the message for a minute ago, really quite stable. So, please consider upgrading, or at least, if you run a hosting company, at least provide the option for people to upgrade. I won't spend too much time dwelling on the features of PHP 5.3, because I think at this point they're pretty well advertised. It's been out for about 18 months. The standard library improvements though are some of the more hidden features, but probably where a lot of the work and a lot of the improvements for the average developer actually really come in. Namespace is obviously a great on larger projects. Anonymous functions I use all the time, but it's some of the smaller improvements that really actually make a difference in 5.3. So, I'm going to make a brief digression into one of those improvements. The crypt function. Now, before PHP 5.3, the crypt function was an incredibly thin wrapper around your C-Libraries crypt function. On some operating systems, your C-Libraries crypt function is actually quite good. On some operating systems, you get a hashing mechanism that was probably outdated 20 years ago. As of PHP 5.3.2, we now ship implementations of a number of common hashing functions within our own implementation of crypt, which means you can use it and be sure that on Windows, on Linux, on FreeBSD, on Vax, apparently people can pilot for Vax, you will actually get the same algorithms. So, for example, you can call Blowfish using that and you will actually get Blowfish. This is a good thing. What this means, of course, is that if you're doing passwords, there's really not much reason to call hash anymore. Obviously, if you're hashing files, go for it. But if you're actually dealing with passwords, I would very strongly urge you to consider using crypt instead because crypt will take care of a lot of the details that before you've had to use libraries like Bcrypt to actually deal with it. Crypt will make your life easier in 5.3. It's also very well documented now, too. So, please go ahead and use it. So, where were we? 5.3, as I said, is still being fully developed. It obviously gets all the bug fixes, crasher fixes, security fixes. It still gets the odd little feature here and there. If somebody posts a feature request on the bug tracker that is sensible and we can implement cleanly or better yet comes with a patch and implements it cleanly, we tend to sneak them in. So, 5.3 is not going anywhere for quite some time. It will be, well, I'm not gonna actually put a number on it because it'll probably end up being wrong, but I'd say you've got a good couple of years minimum before we even think about deprecating it. It's a good release, it's a good branch, and it's gonna keep going for a while. So, where are we headed? Well, to talk about the future, we're gonna need to talk about the past little bit. Let me take you back to the mid-naughties. PHP 6 was first branched back in, I think it was 2004. No, it must be 2005, if I said five years on the slide. Of course, when PHP 6 was branched, the world was quite a different place, and the aim of PHP 6 was effectively to bring Unicode into the language. As it turned out, that turned out to be quite hard to do without actually changing the language fundamentally, and it kind of turned out that really, things like MB string and ICONV and those sorts of solutions were actually sufficing for most people. What PHP 6 did, though, was it basically operated as something just on the horizon that people could look to and say, well, we'll fix this in PHP 6, or it'll be better in PHP 6. And so it became the default resolution for things that were in the too hard basket. And when your entire release is in the too hard basket, funnily enough, you don't tend to actually release it. One thing PHP 6 did do, however, is it spawned a hell of a lot of books. This was the one I wrote. But apparently, they couldn't actually print that because the entire thing was made up of four-letter Germanic words. PHP 6 was finally mercifully put to death in March. Finally, because it really had just been hanging over our heads for a couple of years at that point. Effectively, Trunk got re-branched off the then state of 5.3, the stable branch. Thank you, Joel. Just for the people up the back who can't see Joel's laptop, he has Python is better in very large text pointing at me. Him and Tim did give me a lot of suggestions for this talk, it has to be said. So we re-branched a new Trunk off PHP 6 and basically went through a process of deciding what should actually go into Trunk. Assuming that we actually wanted to get Trunk out at some point, say, maybe this year rather than in 2015. Or possibly about the same time as Perl 6. So Trunk, please, don't write books about this talk. I beg of you, if we get a glut of PHP 5.4 talks, somebody on the PHP project will probably end up deciding to reset it just to piss you off. So Trunk, it will probably be numbered PHP 5.4. There are actually four options for the numbering. Yes, that's how few decisions we actually make. It could be 5.4, it could be 5.5, it could be 6 or it could be 7 because if we go to 7 then the books that said 6 suddenly become outdated and hopefully people won't read them. It has fewer user-visible features than PHP 5.3, which isn't really a bad thing actually because PHP 5.3 changed language quite fundamentally in quite a lot of ways. As I said, the migration path is actually not too scary but there were a lot of changes in there and I think if we had our time over and Trunk hadn't been there as previously advertised as PHP 6, 5.3 probably would have been numbered 6. It is however still quite an interesting release even with relatively few user-visible features and I'm going to quickly run through a few of the changes. Things that have been removed. Registered Globals is finally dead. It's been disabled by default for a long time but we actually drove the stake through the heart. Safe mode is also gone because although it was a mode so the name was half right, it wasn't actually safe in any way, shape or form. Other things that have been removed. SQLite 2, given that it hasn't had a release and has been in of life for about three years at this point kind of seems silly to keep bundling it, the SQLite 3 API I do feel compelled to note is remarkably similar. So migration is not too tricky although you might want to go to PDO. Computer break and go-to have been removed. Who knew that break and go-to and continue could actually be computed? Anyone? You poor people. Go-to unfortunately remains so does magic quotes, sadly. I am campaigning to get rid of it but I don't think I'll succeed. Well, we're actually planning to replace it with MySQL hyperreal escape string to cover the extra dimensions that physics seems to keep theorizing. No, sadly it remains but I will actually digress from the slides for a second with another public service announcement. MySQL wasn't miles away from, the actual original MySQL interface was not miles away from being deprecated in 5.4 because we've had PDO for a long time now and last QLI and it would really be quite nice if people started using them. So, yep, don't worry, we do want to. So it's 5.4, it was judged was maybe a little too soon but the education process sort of starts here. So once 5.4 is out, I think you'll find that some of the people on the PHP project, particularly the documentation team are going to start tracking down people on the internet with very old tutorials and emailing them politely and maybe suggesting that they might want to rewrite them because that's really our biggest problem at the moment. People who come into PHP support channels who've just picked up PHP, the easiest way to do a website and they've seen sample code from PHP 4 and they've written everything using MySQL and ad slashes or magic quotes or both. If that. So, new stuff. Let's talk about what's actually being added. The big language feature, the headline feature is traits which as far as I know is in Scala and probably a few other languages as well which I just don't know of offhand. For those who don't know what traits are, they're basically a non-inheritance based method of allowing code reuse across classes. They're effectively mix-ins in all but name in a lot of respects. The way it basically got sold was compiler assisted copy and paste which is actually what it does internally. It pretty much just takes your methods in the traits, slaps it into the class. So I'm going to show you an incredibly contrived simple example of what that actually looks like. So we've defined a trait for XML serialization because apparently some people still use legacy formats and haven't discovered JSON. So basically the implementation of this is left as an exercise for the reader because I hate writing DOM code. We have a class called user which extends some sort of model. So we've already inherited so we can't just inherit from some sort of XML serializer. Now you could implement an interface but then you've still got to write your implementation in each class or you've got to delegate it out to another function, which kind of sucks. So what we've done instead here is class user now gets that two XML method just straight in, that's right in there. And you can basically use that. It has full access to everything, all of the fields within that user class. But basically you didn't have to copy paste it in. You didn't have to subvert inheritance. You didn't have to muck up your user relationships if you're particularly anal about these things. It just kind of works. And as you can see, we've overloaded the use keyword. Oh good. So basically you can call it like any other method on the class and it just works. Blissful. Other things that have been added. The top item I think is actually going to be quite popular. It's certainly quite popular with me because it's been pissing me off for about 10 years. Implicit's empty scalar object conversion generates a warning, yes, in current stable versions of PHP if you have a scalar variable of any type that evaluates to empty, you can actually start addressing it like an object and it will kind of magically work without telling you. That causes some interesting bugs. And closures are kind of being completed. They're actually getting a little bit of object magic. In 5.3 there was no agreement on how closures should actually interact with objects. So there will now be a little addition which will actually allow you to bind a closure to an object and therefore when you call the closure it will actually have the object scope and will actually act like a method. Other changes, the DBA extension which is not one of our more commonly used ones but it's actually quite cool. Now sports Tokyo cabinet which of course is a blazingly fast flat file database. You get a JSON serializable interface which works much like serializable. And I only mentioned the JSON in code one because A it was annoying me and B I actually wrote it. So I'm just gonna up myself here. One more thing, PHP is not very fast. It's not the slowest language out there, thanks Ruby but it's not actually all that fast. Now in 5.4 we're going to bundle APC but it will be switched off by default but you can go into PHP.ini and with one line you get an op-code cache. This is kind of an improvement. Doesn't stop other op-code caches, I like X cache personally but you have the option at least of just doing it out of the box. Doesn't actually help with the engine itself though. I mean on command line APC gets you nothing in effect. So the good people at Zend have been working on this and there are many, many tweaks in trunk to the Zend engine, none of them major but they all do interesting things which I don't particularly understand so I just pulled the buzzwords out of the emails and just put them on that slide. So hopefully they mean something to you because it didn't mean anything to me. In the real world you get speed ups up to 20% without using an op-code cache or anything. Most popular frameworks we found improved performance from five to 10% and memory usage is also down. PHP is a memory hog, we all know it. If you use an object, there goes half of usable space. We've managed to shave some bits off that as well. So 5.4 aside from traits and all that stuff which is all lovely is actually going to be quite a lot faster and a little bit slimmer. So in short PHP 5.4 should be really cool. Assuming we ever get the damn thing out. I'd love to tell you when it's going to be out. I actually don't know. Every time we get close to an alpha some sort of argument kicks up and it doesn't really happen. The code that's in subversion is ready for an alpha. It's ready for a beta probably. But there's just some internal politics that to be honest give me the shits. So it will be out. I'm hoping it will have an alpha out in the next month or two. And at that point I encourage you all to have a play with 5.4. So I think I've got a couple of minutes for questions. Anybody has any questions? So raise your hand and we'll try and run a microphone to you. Questions? Surely people have opinions on PHP in here. Don't give the microphone to Tim or Joel. Go see. Dumb question but what's APC? OK sorry APC is an opcode cache which basically out of the box PHP even when it's running as a module within a web server reparses your source files each time a request comes in for that source file. Now if you're using a large framework and they all seem to be bloated for some reason these days if you're using a large framework with its own template engine even though PHP is a template engine then you basically could have a couple of hundred K of code getting reparsed every single time it gets hit. That kind of kills performance as it turned out. What APC does is it basically caches the opcodes because like most interpreted languages as a VM internally caches the opcodes for that VM and then on future requests it can just spit them straight into the executor which is actually a huge win and if you're not running an opcode cache and you're running a decent sized public facing site you probably want to. APC happens to be the one that's developed among other people by Rasmus who of course is our BFDL so BDFL did I just... You know what I mean. So he's our Rasmus. So basically that's going to get bundled but turned off there are about three or four of them out there so basically what that means is with one line in your PHP.ini you should be able to get a decent performance improvement out of the box. Any further questions? Steve, there's one up there for you and actually two. Hi, I'm not a coder so I will use your theory just repeat what I heard out there. So I heard out there that hip hop released by Facebook is something that maybe will do PHP faster. Your comments on that? Hip hop will do PHP faster in a lot of cases. Okay, what hip hop does and I'll keep this very quick because I am running out of time now hip hop converts a PHP code base to a C++ code base which calls a library that ships with hip hop which basically re-implements the PHP standard library and then generates a native code executeable at the other end which can have a bundled web server. This actually, it turns out it works really well it is however quite complicated to get going and like most re-implementations does lag a bit behind the official implementation it's only really at 5.2 level at the moment in terms of language support. It is quicker but I think in practice it's probably only really worthwhile if you are in the same ballpark as Facebook in terms of load because for the vast majority of sites your bottlenecks tend not to be PHP or Java or whatever you're using as your implementation language it tends to be your database and caching layers that tend to be your problem. So using hip hop doesn't necessarily get, gains you complexity without necessarily doing much for your actual performance problems. If you're a Facebook or if you're running something that is actually particularly CPU constrained on the web server side then hip hop may well be worth looking at. There's one more behind you and we'll make that the last question. Just to go back to the APC stuff is there any sort of performance constraints with APC if you're in a fast CGO? APC is, as I understand it, a little and bearing in mind I actually don't run it personally, I run XCache. APC is, as I understand it, somewhat less useful in a fast CIGI environment it still works and it still does what it says on the box but depending on the way the processes have been set up in fast CIGI it may or may not be able to share the op codes across processes which of course will diminish your win. Now if you're getting hit heavily then it may not be a problem it's probably still a good win but you might just lose that little bit particularly on server start up because you might be re-imper interpreting the same files multiple times. And XCache? XCache does some evil evil things but actually is pretty quick. So if you care about speed and don't really want to look at the man behind the curtain XCache is pretty good. Okay everybody please thank Adam Harvey for his talk.