 We're talking about speed, I put a bicycle motorcycle there because I used to work on making motorcycles go insanely fast, that's just something I've pinched off the web. I thought it was an imaginative use of used aeroplane parts, make motorcycles not war. So who's been out in front on the river? You see the Pollywood side, it's one of the last of the great sailing ships. What was one of the most important things? Ways of making money in the days of the sailing ships. Import spices and tea from China, take them across to London and the faster ships for the clipper ships and they got the spices and tea to London while they were still fresh so the rich people paid a premium to get the product fresh, the most profitable way of running the business. The equivalent today in Sydney, there's a frock shop that offers three hours delivery, so you're sitting in the audience here if this was in Sydney, you get a date, comes in on your smart phone, you can immediately order a new frock and you can be out the door at five o'clock with a new frock ready for your date. The site doesn't mention discounts, they don't have to because people will pay a premium for speed. There's a ship that used to dock just down there and that was coal powered steamship. Steamships were slower than the clippers but they had a constant speed because the clipper could run into two weeks of no wind. There were products you couldn't put on sailing ships because you didn't know how long they'd be at sea and the products would go off but with a steamship you knew exactly how long it would take to deliver it. So delivery times and all those sorts of things, great. So you want to know when you're developing webpages, you want to know that they're fast and you want to know that they're consistently fast. Incidentally, that ship is a Werfer. My grandfather used to be a pilot in Melbourne, Harbour. He used to be on that ship and that's where my mother learnt to walk. The first time she stepped off the ship was to go to school. Shop Fast was one of the first successful grocery shopping sites in Australia. They used to have below average speed. They would get no registrations because the pages were so slow and no registrations meant no sales. They asked me to do something so I made it above average speed. They got people registering. They would get people shopping once. And above average speed works when people are buying one product but when they're going through ordering 100 products, every half a second on every page is multiplied by 100. So I came back and I made it way above average speed. They got a thousand percent increase in registrations, a thousand percent increase in sales and their bottleneck became the warehouse. Couldn't get product onto the trucks fast enough. So speed makes a difference. What do your customers want now? They want more than a search. They want you to remember previous searches and let you improve on them. They want shopping for shoes. So I want to look up Masala because it's the color of the ear. They don't want just a choice of red, green, blue, that sort of thing. So you're putting a lot more code into your site and you've got less chance of caching the code. Everyone says, oh, cache your output. But every time you add more detail, more choices, there's less chance of something working in a cache. Your customers want personal settings. I want to choose a size 10.540. No preservatives. Left-handable. Left-handable is a really important accessibility issue because 75% of the population are limited to their right hand. Left-handers learn to use both hands because most of the products are right-handed only. So we should, by law, make all products left-handed. So right-handers will learn to use the left-handed. So we move on to droop-late. There's performance issues. That link takes you to a page where they're talking about regression issues. So if you're working with droop-late betas and you find something really slow, please report it. Someone might do something for it. Droop-late, big work on cache. Make caching faster. They've got this tags edition. It's designed to make deletion of cache entries faster, but it's a long-text field. So when you do a deletion of cache entries, you've still got to do a search on a column. That's the sort of thing they put in there. So an ID might be values node one. And it's got these two tags attached to it. Instead of trying to say delete values, colon, node, colon, asterisk, or do a like, you can just say do like node values and delete everything. Sounds fun. What I'm hoping in Drupal 9 is you'll be able to say, I want to store stuff by user country. So I'll get a cache called cache user country. It'll be indexed by user country, primary key. I'll be able to have a custom cache for exactly what I'm storing. It'll be instant to access. It'll be instant to delete, change, whatever I want to do. But cache is not everything. Yahoo! Say you should reduce a number of things on your page to make your page faster. In Drupal 8, it's going the opposite way. What it's doing is splitting the page up into little bits. There's more collective junk the first time you download a page. But things like blocks can be cached separately. So they don't have to be reloaded on subsequent pages. So it should only be your content that gets reloaded. So they're going the opposite direction. But in theory, it will add a little bit of speed. After all these tricks, you still need faster code. You're going to have more code there. You're doing more for customers. You're doing more custom processing for them. You've got somewhere the code has got to run faster. Here's a comparison of various frameworks and ways of doing things. On the left, you've got something written in C code or assembler, super fast, 100% efficiency. Then you've got PHP using an opcode cache, totally optimized for doing whatever it's delivering. Then you've got various frameworks. That one there is Hip Hop, which we'll talk about next. And over here is symphony version 2, which is what Drupal later is using. So we've got over here a lot of very slow processing because there's so much code brought in for everything we're doing. It'd be nice to make them run faster. So some choices coming up, which we're going to talk about, HBM, Hip Hop Virtual Machine, the replacement for Hip Hop, PHP 8, and Zephyr. So HHVM, backed by Facebook, they brought out Hip Hop. It was a pig to use, really complicated, difficult. They re-engineered it, HHVM. And they actually made it nice. You can, if you're not into administering your own servers, you can go on to test environments that contain it. And what it does is when normal PHP runs, it goes into memory, it gets compiled into Pcode. This compiles into a much denser code, smaller, lighter weight, and it runs against a virtual machine that they've designed. So they can put optimization into it. It's 99.8% or something compatible with PHP. Symphony version 2 works, Drupal 8 almost works. At our modules, there's a few things that they've got to change in code to fit. It's available now. Performance gains are similar to PHP 7 and some of the other things. Out there, I haven't used it. And I know people who have used it have got very varied results. There are some things that Facebook have made it a lot faster and some things are not faster. PHP 7 has produced, gone a different track, produced on average about the same speed increase. But when you look into detailed code, because they've done it differently, they've made different parts of your code faster. So there was a PHP 6 and a PHP NG being worked on side by side. Anybody have a look at the projects, the two PHP projects? Yeah, okay. PHP NG became PHP 7. And what it does is cut down on memory usage. It makes your code faster because it's smaller, use of memory, and when it's accessing data, it's faster. So the hip-hop type approach was to make your code faster. This is to make data faster in memory. When they're creating data structures in memory, it's much more efficient, smaller. It's faster to access memory. So your code, if you're running something purely in code, it might be slower than hip-hop. But if you're going through a big array, sorting an array, so it'll be faster than hip-hop. There's a basis for additional improvements. PHP 7 is similar to Drupal 8. It's going to three levels of versions. And there's going to be some additional like 7.1, 7.2, and 7.3. I haven't used that either. But it's due about the end of the year. So the end of the year, have a choice of hip-hop, PHP 7, Symphony 3 will be out. So whether Drupal 8.1 might go to Symphony 3, I haven't seen how much different Symphony 3 is going. So at the end of the year, it's going to be a lot of options. Zephyr is the other thing we're going to look at. There was a project called Falcon. Falcon version 1. They wrote an MVC framework in C, compiled it up. It's insanely fast. It's about halfway between nothing and Symphony. It's a medium-sized framework. I would have liked to have converted Drupal 7 to Falcon, but there are a lot of work. The tests that I've run, it's close to bare metal processing. It looks like if you go through all the different frameworks, it's good enough to do a shopping site. But I'd put it up against something like Drupal 6 or Drupal 5. You could have converted that easily. But when you get onto the complexities of what they're doing in Drupal 8, it doesn't have everything you need for Drupal 8. All three approaches, HIPOP, PHP7, and Zephyr, are all moving to static variable types. The big slowdown that you can't get around in conventional PHP. Every time you work with a variable, the first thing PHP does, it has to say, is this a string or is this an integer and so on? So what's happening in all these rewrites of PHP is an option to say, this is an integer. I'll work with this purely as an integer, and PHP, or the code internally, doesn't have to check whether it doesn't have to convert quote to quote into an integer too, because it's always going to be passed around as an integer too. And that's the next big speed challenge. That means changing a code to specify the data type. So I'm hoping they're going to do that in Drupal 9, make use of one of those three technologies. In PHP7, they're talking about having static variables but not immediately or not a comprehensive solution. Hip hop, there's mention of it. I haven't looked up the fine details. I have used it in Zephyr. Now what happened with Falcon going to Zephyr? The people writing Falcon in C thought it was too difficult. So they started writing a compiler from PHP to C and then compile a C into Falcon. And then they were looking through PHP, and they said static variables. Let's introduce static variables. And everything within Falcon could be passed around as static variables, and that lets it run faster. They still support old style variables, so you can use old style code. So Zephyr should be a nice, easy replacement for PHP. But then they started getting too zealous, and someone said, oh, look at this JavaScript style array syntax. Let's use that with no support for old PHP syntax. So you've got to change your syntax. So converting from PHP to Zephyr is no longer an easy task. You'd only do it for code that's used frequently, and you do it just a small part. For something like Drupal, I'd convert the Bootstrap code to it. There's Zephyr is slightly behind the PHP 5 stream. It's about PHP 5.4. If you want to get all fancy with interfaces and stuff, it doesn't support some of that stuff. I'll give you a quick example of what it's like. You sort of create a directory, you create an outline, and then you do normal code editing and a compilation. Create a directory somewhere. I was going to convert Drupal 7 to Zephyr, call it Drupal 7. First thing you do is say Zephyr init, and you give the name of your project, and it creates an outline. And this is the outline that you get. Your code will go into that directory. There's some... The stuff here is internal to Zephyr. There's this configuration file. You can change it. I've never had to change it when I've been experimenting. Then you create code. That's a classic hello world type thing. There's some hard-coded rules about upper and lower case. It's approximately... If you follow PSR coding conventions, it's approximately PSR 1. Drupal 8 went through the big conversion to PSR 1, then PSR 4 came out. They went through the big conversion from PSR 1 to PSR 4. This is still at PSR 1. Then you do a compilation. You say build. It reads all those files, does stuff, asks for your password, installs the compiled result as a PHP module. And you then have to edit PHP any to tell it to use a module. Now your code is a binary, running at binary speed. When I've tested some conversions of code, I've created some incredibly slow pages that have a lot of code going around, around, around. So they take five seconds to execute. So I can put in microtime and show the start time, the end time. And when I run it in an extension like that, often the start time and end time is about the same. It's so small that it's at the level of inaccuracy of timing. That's four things that are executing in code. They haven't gone through and, from what I can tell, and changed the array structures. So if you're comparing it to PHP 7 on code that does a big array processing, it probably wouldn't be very far ahead. For anything that's running a lot of code, it's way ahead. I don't want to say how to sequence it. So the new ways of making PHP faster, they're all looking at getting close to executable code. Zephyr is the fastest, but it requires most code changes. HipHop's available now. You can experiment with it now. And it works for, I think, things like exec. You can't use. It's a very small list of things you can't do. But it doesn't do much for large data rate processing, variable processing. And I haven't looked at the extent where they've gone in terms of specifying static types and stuff. PHP 7 will be easier to use when it does come in. It'll use less memory. If you've got a 32 megabyte Drupal 7 and you convert it to Drupal 8, you'll be told to use 64 megabytes. And when you get up to Drupal 8, beta 6, it'll crash. And you'll have to go to 100 megabytes. So having PHP 7 bring that memory usage back down. Possibly, if you're using Drupal 8 with PHP 7, you might get back to 32 megabytes. So I'd prefer to use PHP 7 to hip hop. And I won't be converting sites to Drupal 8 until the end of this year. And PHP 7 will be out at the end of this year. Static variable types. I've experimented with them in WinZephyr. Makes a difference. The experiments I was working with, code was using lots of integers. And there were integers that were coming in as strings, being presented as strings and sometimes passed around as strings for various reasons. And I converted the code to immediately change the integer everywhere until the actual point of display. It made a noticeable difference. Just changed a few integers. It was not enough to measure accurately. And when I got onto big arrays of variables, I think PHP 7 looks like it would do a better job. So I'd like to, I'm hoping, Zephyr will get all the features that have been put into PHP 7. The two of them, put them together and maybe make the PHP 8. Put some things from... Take every... All the good points of Zephyr and put them into PHP 8. I've made the presentation nice and fast. I've spent many, many years working on code and working on hardware speed before that. I built the world's first programmable hardware cache. And I forgot to patent it. I actually offered it to people as an open source design about the software and the hardware. And at the time, there was no open source design. So nobody took it up. And about 10 years later, all these hardware companies started going, oh, let's build hardware caches. And now, of course, every disk that gets delivered has got a hardware cache in it. And just about everything's got caches all over the place. If you think of questions after here and you want to send them, anything about Zephyr, I'll answer, anything about Hip-Hop. I don't have Hip-Hop running anywhere. But I'd love to hear from someone who is using it with Drupal. That's where that photograph came from of the Werther. I couldn't find my mum's photographs of when she was a little kid on it. We're going to questions. I've got some industrial hearing loss. You can't actually sue a shotgun for damaging your ears when you're a kid. But you can sue businesses that have noisy machinery. So that's why I call it industrial hearing loss. Questions. Before Zephyr, there were several PHP compilers. Projects to compile PHP to an intermediate language that will be like C or C plus and then compile it to binary. None of them had support and they always stayed too far behind PHP. Someone came along and said, let's build an MVC framework. Let's do a compiler. Before that, they said, let's do a PHP framework and let's write it in C. So all these people using C and PHP write a framework. That's Falcon. If you look up Falcon, heaps of pages on it. There's a framework and there's a CMS called Falcon I which is built on the Falcon framework. And the Falcon documentation's also got a nice little record shop as a demo application. Then the people working on that said, why don't we write in PHP and compile the PHP to C then compile the C to binary? And they appear to have written their compiler from scratch. They haven't used the previous two projects. And along the way, they've said, let's put in static variable types because that's a real problem in PHP processing. And someone said, I don't like array syntax. Let's use square brackets. And I find it much, much nicer to work with arrays in that syntax. But I hate having two bits of code doing the same thing with different syntaxes. I'd rather use rubbish syntax with that everyone's doing the same. And then, of course, now we're all using JavaScript. So much JavaScript when we're using two syntaxes anyway. So I'd be happy for PHP to switch to the JavaScript syntax and then these young kids that have come in and who've learned JavaScript first, it's easier for them to learn PHP. So I haven't seen much support for Zephyr because Zephyr, six months ago, Zephyr was only 96% compatible with PHP or something. There's a checklist. What they're doing is bringing out Falcon version two, written in Zephyr and there's a checklist of all these tests, compatibility tests. And they got up to 95 out of 100, then 96 out of 100. So they're only working on compatibility with Falcon so that Falcon version two will be running exactly the same as Falcon version one. And they're not trying to get compatibility with Drupal or anything else. I experimented with it. I wrote an automatic code converter and the Drupal 7 code is so bad that I gave up. In Zephyr, everything has to be classes and every class has to be its own file. If you go into the Drupal, the bootstrap file, bootstrap.inc, there's several classes, there's spaghetti code, horrible. So converting that automatically is not possible. It's, well it's not possible in my brain, not even with three cups of coffee. So I then did Drupal 8 and I started converting Symphony version two Symphony version two has got some beautiful rules about how the code should be presented and 80% of the code fits their rules. There's a whole lot of legacy code. So there's a whole lot of code that doesn't convert easily. And when you write a rule to change, let's say you've got $x equals array, that might be written three different ways. So I stopped doing that. And when you're compiling up in a namespace, like you've got Symphony component X, Y, Z, it was too difficult to do the whole of Symphony. So I went down to one of the components. So I think it was HTTP request. And I thought I'd just do that. But even with the first two components I could select it, both of them had good code and bad code structured. So it wasn't easy to convert. And I put in a request on the Zephyr, this is Zephyr forum or this is a Falcon forum I linked in and I put in, someone wanna work on this? Nah. Well, someone wanna help me with regular expressions. Regular expressions is worse than venereal disease from what I can tell. You don't wanna do them yourself. You want someone else to have to work on the regular expressions. So nobody volunteered. And if you try and work out something like $x equals array bracket, end bracket thing and convert it and you allow for comments at the end and all the different things that can be inside the array. And all you wanna do is convert array opening bracket to a square and the end closing bracket semi-colon to a closing bracket, the square bracket semi-colon. But the combinations that you can find there, you gotta go across multiple lines and code and stuff. That's way over my head for regular expressions. So if I had access to a regular expression guru, I could probably do it. I did some string splits type things using explode and all sorts of stuff and it worked where for simple examples, but complicated examples I just gave up on. So I'd say 50% of the code you could convert automatically and the other 50% you'd have to do it by hand. And I think if you had a team of two or three people on each component in symphony and we only use about eight components out of the whole of symphony it's only about eight components or 10 components in Drupal 8 and if you had a little team on each one you can convert them and compile them up because in terms of namespace, when they're module, you're compiling a module that goes into PHP it can be the end bit of a namespace so you can have your namespace of symphony, component, HTTP requests, you can just, where I showed you Drupal, instead of Drupal you can compile, you can name it HTTP request and just do that section and someone else could do another section and you could have a big team doing it like that. What's the most frequently used thing in Drupal 8? I've never profiled it, but if you found the most frequently used class you could just compile that class by itself. Boom, it's running at machine speed. Fabulous project for someone to do and they might not even have to know regular expressions because it's only a little bit of code. You change the file name to nn.zep, I think it is, and you take out anything that's not a class and anything that's not PHP it doesn't do anything with the comments. Just it throws everything, a lot of things away. There's all the features, I think it might be PHP 5.3 but not 5.4 or 5.4 but not somewhere closures in the face or somewhere about there, some of the things that are missing. So in Symphony 2, you'll have some code where it'll have a namespace, you're passing a parameter to a function, a method, and it'll have a namespace and a variable name. That namespace is saying this should be an object of certain type. That's not, that doesn't work yet in Zephyr, so you have to throw away the namespace and the static types are purely Inature String, there's about the five static types but for that converting strings to integer and just passing around as integer, huge gain in performance there, binary is a static type. So for the most common things that I do, I could convert to static types. I don't use all the features of, I compile, I use PHP 5.6 but I don't use all the new features in 5.6 or 5.5 and I think Zephyr handles everything from 5.3. So maybe there'll be like 12 months from now, it'll support 5.4 and 5.5 and so on. So it's probably running a year behind Symphony. That build process, it uses PHP to convert from Zephyr to C and it's so fast that first part of the message comes up, boom, that was compiling I think 20 classes or something like that and it's just blank, that's on this little Toshiba. Then it asks for your password so it can install and that's just stuff happening in the background. So the second pile is compiling very fast because it's very small optimized code and the PHP conversion to Zephyr is very fast because it's not doing anything really complicated at this stage. I guess because of things like the variables going into, the parameters going into a method, they're not yet supporting namespaces, they don't have to go off and do lots of big cross referencing and stuff. So if that part's blindingly fast, I'd rather have the extra features and have that take three seconds instead of, three milliseconds. Who's volunteering to. If you're in Sydney, I'm happy to sit there and let you help you run it. There's a fabulous documentation on Falcon and there's almost there documentation on Zephyr. There's a Falcon.org, Falcon compiler.org, something site for Falcon and it's got the sort of, the level of documentation similar to Symphony. The Zephyr one, they've just got bare minimum documentation and we do have the reference further back. Zephyrlang.com, if you're happy with the command line and you're happy with editing PHP on your local development machine, you follow that, that's all I've read. It's about 20 pages. It tells you what to do to create a working example. There's a whole lot of things that it doesn't yet tell you but it's enough to create a working example and try it out. And there's a whole, there's a few things I had to, when converting Symphony, there was a whole lot of things I couldn't find in that documentation. So if you want to write code from scratch, perfect, you're all going to install this for homework. The installation, you install Zephyr on your machine from Git. I found it, because I've used Git before, I found it really easy. I just cloned the repository and it's just running PHP command line in your local directory to do the compilation then it's just doing, compilation to C then it's doing a normal compile. I've also installed Falcon from, Falcon 1.3 and Falcon 2 from Git. There were some problems with them, but the actual Zephyr, boom, went straight in, beautiful. You could actually do it in the break between now and the next presentation. We've got to do static variables to get more speed from PHP, make them optional, do it. This is way of the future, we'll get everything from Zephyr and put it in PHP 7 or 7.1 or 7.2. All right, okay.