 All right, good morning. My slides, as always, are on talks.php.net at this URL. You can follow along if you like. So as of this year, PHP has been out for 20 years. So the old timers in the audience might have been using it for 18, 19 years, maybe. I've been using it a little bit longer than that because it didn't just appear magically 20 years ago. I was working on it for about a year and a half before then. But what this really means is that I just feel old. I've been doing this for way too long. 20 plus years later, I'm still talking about this hack that I did back in my 20s, which is a little bit sad, I think. So this was my original announcement. And if you read through this, it's kind of interesting in that it doesn't really talk about PHP itself. It just talks about the problems that PHP can be used to solve. And it's kind of a history snapshot of what the internet and the web was like in 1995. You can see sort of the problems that people dealt with on a daily basis. And that's how I introduced PHP, because the world was completely different. We didn't have dynamic web apps back then. The web in 1995 was like your morning newspaper. You would go to a site, and you'd see what new content have people put on the site since I went to it yesterday. And some sites wouldn't change for months. And they were pretty boring. So it was just the beginning of dynamic content on the web. So I didn't describe it as such, because nobody knew what that meant. But it's kind of interesting. The PHP part is hidden in these two points here. Easily create and display forms, and the ability to use form information in the following documents. So I mean, you put it in a database. You have variables. You can pass things around. So that was the introduction of PHP. Posted on Usenet, which most of you have probably never heard of. But this is what old timers like me used instead of Reddit. And actually, my project completely failed, because what I was trying to do was create this C API for the web. Those tools were just a set of tools I had written using the API to get users. But the developers, I was trying to convince them. And then in the documentation for PHP, it described how to build more tools, how to write more funky tags that you could put in your web applications. And I had never thought that someone would write big, complicated applications in the templating language that was part of PHP. My intent was that you used a strongly typed, compiled language, in this case C, to build your business logic. And you would just put your presentation layer. And you would extend that business logic. And you would expose these custom tags to the presentation layer. And you would use that only at that layer. What I didn't really understand was that nobody wanted to write C. And the web was growing so fast that there was just no way that there were enough C developers around to meet the demands of the speed at which the web grew. So this idea of mine that you would just write a bit of the C code, and it was stack-based. I thought I made it super, super easy. So you didn't have to be much of a C developer. You didn't have to understand HTTP. You didn't have to understand Apache or the web servers at the time. All you had to do was write a tiny little bit of business logic and toss it in. So you would pull arguments off the stack. And you would push the result of your C code back onto the stack. And then you would have this new tag that you could use in your HTML. I thought it was a very nice solution, but nobody wanted to use it. So they simply just used the examples that I had provided. And they kept complaining and filing bug reports saying, well, we need this tag. We need this tag. We need this tag. And I kept showing them, well, that tag is super easy. It's like 10 lines of code. Here you go. I was like, thank you. Now we need this tag. And it just kept going and going like that. But anyway, that was the beginning of PHP. And like I said, it completely didn't work out the way I had thought it would. It worked out on a different tangent. And at a certain point, I kind of gave up on my approach and said, OK, fine. People want to just use the templating part of PHP. I think it's crazy, but let's just go with it. And let's fix up the templating side of things and make it work better. And that's when PHP turned into a full open source project because I needed a lot of help to turn that corner. Because then we have to provide connectivity to tons of databases. We had to do all kinds of stuff. I had provided a few, but there's no way I could support 20 different databases, for example. So I needed tons of help at that point. Now 20 years later, we're getting ready to release PHP 7. Hopefully in the next six to eight weeks, if things go as planned, it's, to me, it's the most exciting release of PHP that we've ever had. Mostly because the performance is going to change the world, I think. There are so many sites out there running stuff written in PHP. Lots of people don't even know it's in PHP, and they don't really care it's in PHP. But when everything starts being twice as fast, it's going to make a difference. Think of just the green server movement. Now you need half the servers and the data centers to serve up all your WordPress and Drupal stuff. Realistically, people are simply going to pile more things on top, and they're not going to reduce the number of servers. But in theory, they could turn off half their servers and make the world a greener place. We'll see. We have a bunch of new features. I'll just do a quick overview. There'll be other people talking about PHP 7 here. But as a quick overview, we have a persistent file-based cache now for OpCache that you can turn on. So the way OpCache works, it caches stuff in shared memory. Caches the compiled OpCodes in shared memory. But you can also have a file-based backup now. So in case you have to restart your server, the hit on having to recompile every script is not as big anymore because it can repopulate the shared memory cache from a file-based cache. And these numbers here just show that if it's 1x to recompile your script every time and run it, it's about 10x. It's about 10 times faster grabbing it from shared memory, and it's about four times faster grabbing it from disk. So one use of this is that you can turn on the file-based cache for CLI. For CLI, you can't really use shared memory. Well, you could, but every time PHP shuts down at the end of your CLI script, it's going to delete the shared memory segment. It doesn't persist from one execution to the next, but the file-based cache does. So the way you do it, you compile PHP with enable OpCache file, and you give it a directory to tell it where to cache files in, and then you can enable it in your PHP CLI.nni. You can say, please turn on the file cache. And I tested it with Composer, which is one CLI script that most of you probably use every now and then. So running Composer the first time where it has to compile and cache to disk took 0.04 seconds. Then the second run of it took 0.019. So it was about twice as fast the second time I ran it with a cached version. Without any caching at all, it takes 0.033. So the first time you run it, it's slightly slower than without a cache, but then next executions are quite a bit faster, not that you're really going to be affected that much of 0.03 versus 0.019 seconds. But in general, if you're doing a lot of CLI stuff, you have cron jobs, all this stuff, you could speed up everything, even at the CLI level, by quite a bit, plus the fact that your code itself is going to run faster in PHP 7. This is PHP 7 versus PHP 7. If I had done this one, or this last one here with PHP 5, this would be taken quite a bit longer. So the combination of the file-based cache plus the speed of PHP 7 means that your CLI scripts are going to fly much quicker than they've ever been before. This is what actually shows up in the file-based cache when you run Composer. You probably didn't know how complex Composer actually is internally, because you get it as a single file. It's almost like a single file PHP script, but it's really not. It's a FAR script, so it's a PHP archive script. And inside that archive, there's a lot of crap. Tons of, well, I wouldn't say it's crap. Some of it is actually. Some of it is not very good, but most of it is pretty good. But it's not as simple as you think. It's not just as a single command line script. To me, the most exciting feature in PHP 7 outside of performance is the AST, the abstract syntax tree. So to get from the script on disk to the op codes, we now go through an AST, meaning that you can go in there and you can grab the AST, and you can look at it. You can even modify the AST and do interesting things. And when you have all the syntax in a fully functioned AST, there's a ton of things you can do. So in this case, here's an example AST. So this is just one line of PHP. Echo substring, ABC, then array one, two, which is obviously not very syntactically or grammatically correct. I mean, substring does not take an array as the second argument. But the AST that you get from this is that you get a statement list. You see there's an echo. Then AST call means we're calling a function. The name of that function is substring. This name, not FQ, means the name is not fully qualified because it's a global function. So if you put a backslash in front of it, it would be a fully qualified name. But PHP defaults back to the global namespace. So it's not fully qualified, but it'll figure it out that it's a global function. The argument list is ABC, and then an array with two elements. Now, I wrote a little static analyzer, and I'm sure there'll be plenty of other static analyzers, hopefully, that come out, because it's quite easy. If we're within about a weekend to actually walk through, it just becomes a tree traversal algorithm. So you walk through the tree, and then you pick out the things you're interested in checking. And in my case, I'm checking all kinds of stuff, including function calls. So here I see, okay, I see there's a function call, I know it's a substring call. I have a little file that has the type of arguments that a substring call takes, and I just compare it, and I see, wait a second. That second argument should not be an array, and I can throw an error, saying, hey, I was expecting an int, but I got an array of integers, and I can throw a static analysis error and say, uh-uh, there's a mistake. If you run this static analysis on a pre-commit hook or something in Git, you can very quickly, or you can even run it from the command line every time you change something, run static analysis across your code to catch any mistakes like this, just in case your tests are not fully covering all your code, which is usually the case. All right, types. We've added a bunch of types, including return types. The syntax is this, function colon, and then the type that the function should be returning. If you've returned the wrong type, in this case, I was supposed to return an array, I returned an integer. You get a catchable fatal error telling you that you have the wrong type, right? We also have types on function calls now, two versions. There's the cursive scalar types, which is basically how PHP works today, at least for internal calls. You can specify that you want string in float, and if we can, losslessly or at least without any weirdness, convert the types. So if you pass in a one to something that takes a string, we can figure out, okay, well, we'll just turn this one into a string, and it'll work. Internally, you will get string int and float to work with inside your function. But you can also make it strict. You can say, I don't want to do coercion. You'll still get an error if you get it way wrong, right? But if we can curse, it's fine in cursive scalar types. If you turn on strict mode, then when you make this call, even though we could easily turn this into the right set of types, you'll get a fatal error on the call, right? So argument one passed a log message, must be of type string, but you passed an integer. If you want to be really strict, you can do this. If you turn this on for existing code, nothing will work. So mostly this is useful for new code, or at least for refactoring maybe the inner parts of your existing code, but just turning on strict everywhere, all PHP code ever written basically break, because it was written for coercive typing, and PHP has always done that. So there's no way we can just turn on strict everywhere. Everything would break, and that would not help us. Anonymous classes. Just like you have anonymous functions, right? You don't have to declare the class anymore. You can just say return new class directly, like that. Oops, sorry. There's a null core less operator. This one I quite like. So this will not warn on undefined variables. So it'll go through and it'll return the first thing that is PHP truthy, right? So A or B, A is null, which is false. B is one, so this is gonna return one. C or B, both B and C are set, so it's going to return the first one. It's gonna return C, which is two. A, B or C, so A, B or C, B is the first truthy value in that, so it's gonna return one. A, X or C. So A is null, X is not even defined. C is non-null, non-true, non-false, sorry. And you get two. But you will not get a notice on this X. So that's the whole point of this operator. Otherwise you could use question mark colon basically on it. We have a spaceship operator. I had an interesting discussion with my son about which exact spaceship it is. We went through a few, tie fighter, tie interceptor, tie bomber. He tells me quite authoritatively that it's a tie advanced, X one. And so this is how a spaceship operator, this one, right? And the main use of this operator is in comparison functions for user sorts, type functions. So whenever you write a comparison function, it should be stable, meaning if A is less than B, then B should be greater than A when you compare it the other way around. So it should return negative one, zero or positive one, or at least positive value. And we've had problems with people writing unstable comparison functions. So the comparison function would claim that A is less than B and that B is less than A. And then sorting gets very, very confused. And you get weird results and people file bugs and we look at their comparison function because they got this type of code wrong. Now, with the spaceship operator, you don't have to think, you can just say, A, spaceship, B, it'll do the right thing for you. Exceptions on fadals, most fadals now are actually exceptions. Now an uncaught exception is fatal, so it's not going to change your existing code, but it gives you a bit more flexibility in that you can go in and you can catch these fadals and handle them more gracefully than you could before. The most common one is this call to member function method on a non-object. So you're stringing a bunch of calls together, one after the other and you don't realize something in the chain of calls can return null or false or something that's not actually an object and the whole thing falls apart. Then you have to break apart your chain and you have to do error checking along the way on each one, which is a bit of a pain. Now you can throw a try catch around the whole thing and if something in the chain didn't work, you can catch it and do something more intelligent with it. There's a closure call now, so you can go in and you can specify which class to apply and you can call the closure with a user defined class. It's a bit of a geeky feature, mostly for frameworks, but it is handy in some cases. And we have broken all kinds of PHP4 things. So if you're still relying on extEreg, for example, the old regular expression functions, you need to finally go and fix that code and upgrade it to use PCRE. We've removed the eval modifier in preg replace, the slash E, which basically did an eval on matches inside the regular expression. Security-wise, there's just too many bad things that could happen if you allow evals to run on what is often user supplied code. So now we have a preg replace callback instead. We can give it a callback function and that PHP callback function can be run on the matched data as opposed to just doing eval. You can do exactly the same things, but it does mean that if you have any slash E's in your regular expressions, you're gonna need to do a little bit of work converting it to PHP7. The other things in here really shouldn't affect you. These are things that have been deprecated for so long. These ones up here are the main ones. We also have some new reserved words. So if you have a class named string, it's not gonna work in PHP7. So if you have classes named any of these, you're gonna have to rename them. Hopefully you don't have a class named true. That'd be weird. 64 bit integer support on Windows for the Windows folks. Bunch of cleanups around how we handle overflows and underflows. We also have finally made this a parse error. So if you specify an invalid octal, before it would just give up and say, okay, well, mask is zero and it wouldn't even warn you about it in PHP5. Now you get a parse error on this saying, I don't understand this number because zero eight something is not valid in octal and you'll get a very early parse error telling you that you did something wrong. There's actually caught a bunch of bugs in the Etsy code base at least when I ran it. Now, the trickiest thing you need to watch out for when you're upgrading to PHP7 is probably this part, the uniform variable syntax. Because of the AST, it wasn't possible to support some of the weird exceptions that we had to how we parse when you string together many things. So when you have a class and you reference it to a property and that property is an array, then it's a little bit hard to figure out what does this actually mean, right? Do we take this belongs to and then grab the column element or do we say we take the value of belongs to column and make that the name of the property, right? It depends how you group it. In PHP7, it's always left to right. So the grouping is always this belongs to, so if you have a variable named belongs to that has an element column, that value will then get returned. That's not how it works in PHP5 currently. It'll look in belongs to column and if that has a value, that becomes the name of the property, right? So you can get the PHP5 behavior simply by adding curly braces here. So you can get it to work exactly the same but you have to add curly braces to have it dereference the right side first before it does the left. In PHP7, it's always left to right as you're reading it, which makes it easier to figure out now but it means that if you have code that does this, this is the most common one but you also have other things that could string a bunch of things together that may not have the same parsing order. There are tools, my static analyzer and others out there, PHP parser, that you can run that will pick out suspicious looking code like that and tell you, hey, you might need to have a look to make sure that the parsing order is correct on this one. What we also get though by making this completely standard is that all kinds of weird combinations that never worked before now work. So in this case, if you have a closure that returns an array of other closures, right, this now actually works. Please don't write code that looks like that but if you absolutely have to, it does work. So my presentation tool that I'm using for this presentation, I was actually using a slash E. I had this weird delimiter colon minus colon and I have things like the name of the city I'm presenting in that I can throw into a slide, I can just say city and then I don't have to recreate the slide because I'm giving the presentation a different city. But this wasn't working because all I did before was that this does an eval and picks out the property named city out of this pres. So in order to fix it, I had to change this last E to a callback. So in this case, I write a little callback function here that gets the matches and returns this press matches one. Now, of course, this worked perfectly fine in PHP 5 but in fixing this, I got hit by the PHP 7 problem and my static analyzer caught it, I ran it on it and it said, compact error, expression may not be PHP 7 compatible because I actually wanted this to be expanded first, matches one, before this part. So I had to go in and I had to put curly braces around that, right? So these are the kinds of things you will probably run into when you're upgrading to PHP 7. In this particular case, when you have properties that are arrays that you're dereferencing all in the chain like that, that's the most common thing that you'll hit. There's a new syntax for Unicode code points, backslash U, and you put the code point that you want in there. So in this case, I have a right to left text and then I have a weird smiley face, right? It makes it a little bit easier. If you're just reading code points out of a table or something and you need to stick it into PHP code, you can just type them in directly. There's also an Intel chart class in the Intel extension now. So like I said, six to eight weeks, hopefully, depending on how the release candidates go, they're looking pretty good currently but there are lots of people still that need to test. We need more bug reports from you folks and I'll talk more about that in a bit. A bit more on performance. This was mostly three guys initially, Dmitry, Chanchana and Nikita that sat down all of last year and banged away at WordPress. So they took a WordPress 3.6 installation on some slow computer somewhere and they counted the number of instructions and the time that it took. So if we just look at the time. So it started in January, 2014. It took about 26.6 or seven seconds for 100 requests against the WordPress front page. And then they just went through and iteratively made it quicker and quicker by optimizing things, removing things, making it use less memory and by the end of the year, they headed down to 12 seconds for that same code without breaking anything and they also looked at instructions. So they started off needing nine billion instructions to serve up these hundred pages and by the end of it, they were down to 2.9. So and if you imagine this, this is a 20 year old scripting language. This is a 20 year old code and you're asking the developers, do exactly the same thing, don't break anything but remove two thirds of the instructions that you're using currently to generate that output. It's like taking a complex application you have and say, well, we're only gonna run every third line. Make it work, right? It was an absolutely monumental effort from these folks. And we're gonna see the results of that as soon as we get people to upgrade. So what they actually did was they reduced the Zval size. This is sort of the base unit inside PHP. It's this struct that, this union that holds the basic pieces of data that gets passed around between functions and everything in PHP. So that got reduced from 24 down to 16 bytes. Hash table sizes got reduced. The bucket size got reduced quite a bit and there's also an immutable array optimization. So for example, this code here, if I keep appending to an array and I keep adding more arrays to the array, in PHP 7, this would need 43 megs to run. In PHP 7, it only needs six megs of memory to execute, right? So this is a contrived example that is written directly for that optimization, but by combining hundreds of these optimizations, they managed to get this performance out of this code. It's way more CPU cache friendly. As computers have involved, CPUs have involved caching and compilers. There's lots of interesting things we can do now that we couldn't do just five years ago. A whole bunch of other things have been done. Tons of micro-optimizations and no JIT yet. We probably will get a JIT at some point, but to me, this is quite exciting actually that we got at least two X performance speed up without a JIT, which means when we do add a JIT and the JIT basically addresses hot spots in your code, pieces of code that gets executed a lot, we can speed it up quite a bit more with a decent JIT if we get there, but at least we have the door open for that, so making the base PHP faster leaves us room for another, maybe not two X, but probably another 30, 40, 50% speed up with a JIT. We'll see. So some numbers on this, please don't trust them. Run your own benchmarks on your own code. I've tried to provide all the information so you can, if you really do want to repeat it, and there was a German magazine that actually did that sat down and they specced out a box as close as they could to do mine and they went through and did all the same things and he came back and said, I didn't get your numbers. All right, send me your config. So he sent it along and he had forgotten to turn on opcache in PHP 7. So I caught that in his config and I told him to turn it on and say, oh yeah, you're right, now the numbers match almost exactly. So a German magazine did actually recreate these results that I'm gonna show you. Right, so first off, Drupal 8. So this is PHP 5.4, 5.5, 5.6, PHP 7 and HHVM 3.7. This is request per second at 20 concurrent clients in this case. This is on a four, eight core, yeah, eight core CPU. At 20 requests per second, at 10 concurrent clients, the numbers don't change that much. So they're the same. At 40 concurrent clients, again, the pattern is mostly the same on these. Latency-wise, latency on PHP 5.4 was 15 milliseconds, 14 and PHP 5.5, 14 drops to eight in PHP 7 and 11 in HHVM 3.7 on a default Drupal 8 install. So Drupal folks are going to be quite happy with PHP 7, I think. It's not quite 2x, but it's very, very close to 2x from PHP 5.6. If you're coming up from PHP 5.4, then it's very close to 2x. If you're coming from PHP 5.2 or 5.3, then definitely you get 2x the performance out of it. WordPress 4.1.1, so 5.3, 5.4, 7. Here you're getting more than 2x out of it, mostly because we used WordPress code when we're optimizing and the HHVM folks have been using WordPress as well as the default benchmark. So most of the optimizations apply to WordPress code. That's why you're getting almost 3x on WordPress. So 6.27 across the second versus 6.66 for HHVM. I'm like, ah, damn it, we're not quite there. But I have a solution for that. It's a bit of a hack. GCC has this thing called FDO, which is feedback directed optimization. And it's kind of like a jit built into GCC. So the PHP 7 make file supports FDO. You build it like this, make profgen. This generates this profiling version of PHP. Then you run PHP, so you run basically PHP CGI is the easiest way to do it. Run PHP CGI minus T1000 means run it 1000 times and I was running the WordPress front page, which loads in most of WordPress anyway, so you're getting most of WordPress. So I run it on WordPress 1000 times. Then you say make prof clean, make prof use. That tells GCC to recompile PHP using the profiling data from WordPress specifically. And the result, so this was 6.27 before, 6.64. Now with a PHP 7 FDO, which is statistically tied with HHVM on WordPress 411. So we cut up. This benchmark is about two months old at this point. We have made a few improvements since then. HHVM 3.8 has made a few improvements. So the numbers for the current version of PHP 7 and HHVM 3.8 might be slightly off, but it's gonna be very, very close. But I think the FDO is interesting. If you're a WordPress shop and all you do is WordPress, there's really no reason not to build a WordPress optimized version of PHP 7. Same if you're a Drupal shop or anything else. If you're not an ISP that has to run everything, if you're a shop that runs a single code base all the time, you're much better off doing an FDO build. You don't lose anything by it. I mean, you have to build your own, but you should be building your own PHP anyway. I don't trust anybody else to build my PHP. I don't think you should either. All right, a few other numbers. PHP BB, again, not quite 2x from PHP 5.6, but more than 2x from PHP 5.3. So this is 309 to 727, right? Latency drops down from 65 milliseconds down to 28 milliseconds here. And the latency, it's the first byte latency. So it's the time between the request hits the server and the first byte comes back to the browser. So it comes down to responsiveness, like how quickly does the server respond? How quick does it feel? And once lots of sites upgrade to PHP 7, there's responsiveness. The feel of the sites is going to improve a lot because not only can it handle more load, handle more traffic, but even on a single server instance where you're not too worried about thousands of requests per second, the latency is gonna drop in half, which means all your pages are gonna feel crisper. Every time you click, boof, up they come, up they come. So even on very, very small setups, you're gonna get a lot of benefit from PHP 7. Media Wiki, this one PHP 7 is slightly behind HHVM. HHVM has worked with Media Wiki quite a bit, I think to mostly because of Wikipedia. So here we're slightly behind. I haven't tried an FDO build with Media Wiki. I could, I doubt I would catch them completely. I'd probably maybe close the gap halfway with an FDO build. But even then, you're way better off with PHP 7 than the earlier versions of PHP and your latency drops quite a bit as well. So from 170 or from PHP 5.6, 137 down to 77 milliseconds for a default Media Wiki install. Open cart, this is looking very flat. Basically, this is just an example of an application that is spending all its time in the database. And we're sorry, but making PHP twice as fast is not going to speed up your SQL. If you have 20 full table scans on every single request, yeah, I mean, we're slightly faster and the latency drops a little bit. So latency drops from 72 down to 64 milliseconds, but there's no way you're gonna get 2x out of something like open cart because it spends all its time inside the database. Wardrobe, this was me looking for a default Laravel application. So this is Composer installing all kinds of symphony and Laravel bits and pieces. And you can see the result here from 555 to 1079 requests per second over PHP 5.6, which is quite impressive, I think. Geeklog, another random application I grabbed off GitHub. Again, almost 2x, not quite 2x, but still pretty good. Magento, Magento is quite a beast. It's hard to speed up Magento, but there's a significant jump from PHP 5.6, 48 to 77. Again, slightly behind HHVM in this particular case. Latency drops 412 down to 259 milliseconds from Magento. Track, this is a ticket tracking system. Again, same sort of pattern that we've seen before. This is one of the only ones that I had to fix to work with PHP 7. They had this code in here. They had this model fine belongs to, and this part here, this belongs to column, which is actually the example I pulled out, came out of this track application. All I had to do was add curly braces, sorry. All I had to do was add curly braces, and that made the application work. The secondary aspect of all these benchmarks is that I took all these off-the-shelf applications and ran them and they worked without any changes at all, except this one thing, which I've already submitted back to them and it's now in the code, because once you add the curly braces, this doesn't hurt PHP 5. It'll run exactly the same in PHP 5. So the projects will be upgrading their code to run on the PHP 7. Cache, another application I grabbed, same pattern. Moodle, this should make a lot of schools out there happy. That Moodle is twice as fast now. Zencart, another shopping cart that spends most of its time in the database. You've seen our other optimizations across PHP 5 didn't touch it at all, PHP 7 does a bit, mostly because less memory usage, but not 2x. All right, finally, help us test. Please, please, please. And it's not hard to test this stuff. You don't have to upgrade your production version of PHP. You can just install a VM and run it there or put it on one of your test servers or grab my vagrant box. I packaged up my own development environment in the vagrant box that you can just get clone straight from GitHub. So git clone, GitHub earlier though of PHP 7 dev.git, see the into it, vagrant up. Takes a little bit of time because it has to download the vagrant image, but go have a coffee when you come back. You can vagrant SSH and you'll be in and you'll be in my development environment, which has every version of PHP ever basically pre-compiled for you and it's really easy to switch between versions of PHP. If you go directly to 192.168.77 it'll give you a PHP info page. You can configure your own IPs of course. There are 20 versions of PHP pre-compiled. You can switch between them by typing new PHP. So you say new PHP 5.6 to go to 5.6 and new PHP 7 to go to 7. And there's debug thread safe and non thread safe versions of all the different ones. You can make a new version. You can recompile, just type make PHP 7. My vagrant image right now is maybe two months old. So the first thing you wanna do if you grab it is type make PHP space 7 and that'll grab the latest PHP 7 code and compile and install the debug and then the non-bedeague bug version of it. Or you can do it manually if you like. You can see the into PHP source and you can pull out things. It's not hard to build PHP and it's a good place to practice if you haven't done it before. So that's the URL. Our little PHP 7 dev. So please, please test PHP 7. Don't wait till the final release and then start complaining that we broke your applications. We're not gonna be very sympathetic at that point. You'll get a lot more help if you break your application now and tell us about it. Then we'll be much more friendly towards you. All right, I have, I don't know, two minutes for questions. Let me pass you the mic first. Okay. Hi. Hi. Yeah, I was just wondering, if PHP Infuser versions provide the function overloading that, I mean, in usual OP languages, I mean function with the same name and different parameter arguments. So, I mean, is there any plan to provide the function overloading like other languages are in OP paradigm that we see? No, so you mean multiple inheritance, essentially. No, no plans. Okay, thank you. Easy, others? You mentioned you reduce the hash table size and bucket size. Is there any sacrifice or any downside of that? So the question is we reduce the memory use for hash tables internally. Is there a user space effect? No, you shouldn't see any difference at all in user space other than your script will use less memory. But no, there's nothing at the user space level. If you're writing PHP extensions, your life is miserable because everything internally has changed. So your C level code, your extension code has to almost be completely rewritten to address this. But at the user space level, no, everything is paradise, nothing changes. Everything is just twice as fast, users less memory. It's wonderful. It's not so wonderful if you're a C developer and you have extensions that need to be upgraded. That's a real pain to get that done. And that's the biggest obstacle we have currently. We've ported all the PHP.NET extensions, most of the Pekal extensions, but there's still stuff on GitHub that we don't have anything to do with that are struggling to support PHP 7. And that's gonna be the major thing that we need to address. So in seven years started disabling some deprecated extensions. Is there a performance gain, and this applies also to five, in disabling extensions that are not actively used or is it just nitpickering? So is there a performance gain in disabling deprecated extensions? No, not really. I mean, you get for web stuff, once the code is loaded, probably zero, you have a slight speed up for CLI scripts that have to start up and load in all the shared libraries. You're loading one less shared library for each extension you disable. So for CLI, maybe, but really no. Computers are so fast at doing this these days and there's this caching and all the stuff, kinds of things, so no. It's not a performance thing. Any more question? Do you have any stats about performance for the popular generic frameworks like Symphony or Zen framework? It's kind of hard to benchmark frameworks, which is why I went and picked out a few that uses frameworks. So Wardrobe uses Laravel, right? So I mean, you can run just the tests in a framework, but that has nothing to do with the real world use. Depends how you use the framework, right? Which is why I wanted to pick out some applications that use the different frameworks. So who knows? This particular use of Laravel that implements this CMS system, you saw a huge speed up. Now, everyone uses Laravel differently or Symphony, so whether or not you're gonna get the same numbers, you have to do the benchmark yourself. But in general, framework code will be running a hell of a lot faster. We haven't found a single framework to slow down, that's for sure. And most of them are 2x or very close to 2x. We have time for two more questions. Do you know if the Magento is running ZF1 or ZF2? Do I know if Magento is running what? ZF1 or ZF2, ZF1 or ZF2? Oh, I have no idea. One, I'm two. 21, that's good, thank you. Two, they're working on two apparently. Last question? Nobody wants to be the last question. Well, Rasmus is here. Come on, don't let the last question be a Magento question. Hi, I see there's a framework called React. That's kind of a non-blocking asynchronous. Is that something you guys are considering to PHP Core to enable any asynchronous binaries? Well, I mean, we have asynchronous support in a bunch of places already, right? So no, we can't really do asynchronous everywhere type thing, but you can already do asynchronous database queries with both Postgres and MySQL. You can do event-driven stuff with Live Event. There's a talk at this conference about doing event-driven things. So there are mechanisms to do it. And it's going to be technology-dependent. Each one has its own way of doing asynchronousity. There's no real effort to make all of PHP multi-threaded, for example, which is what it would take to make everything asynchronous that way, so no. All right, thank you very much.