Start in 1993. Mosaic.
Was working for a company building on greenscreen thin terminal dinosaurs, trying to extend tech.
Trying to build apps on these.
We have to move to the web.
Slow to move
So I quit.
Websites in 1993 had a CGI counter on each page that forked a Perl exec. Extremely slow.
What we wanted was HTML with inline exec on every page.
1994 PHP born. Embedded in HTML comment tags.
SQL from the start. MiniSQL.
HTML comments tiring, so read a book on parsers... Rewrote in 1995 to look more like a real language, but with no braces.
2001 Drupal
Same db example is much more verbose... Kind of prefer 1995 version...!
Perl, awk... That set of people
10 years later expectation was object orientation
Not about religion, but about familiar interfaces [pragmatic]
On third try, did a good job in PHP5
5.3.3
Closures
Namespaces with a backslash...! Every other character would have caused parser conflicts.
Constructors in PHP4 - eponymous function
Bugfix in 5.3.3 for namespace class versus namespaced constructor.
Late Static Binding to work out what class the method is called on in the hierarchy
NOWDOC
Ternary shortcut
goto - we had multilevel breaks for ages. This is just a new keyword. If we'd called it a label break nobody would've cared, which shows a lot of people are pretty stupid.
DateInterval / DatePeriod
Performance matters because even e.g. Google PageRank affected by response.
One core VM running 5 concurrent clients. PHP Fast Process Management
Fairly underpowered box.
ENABLE APC or some other opcode cache
Set default timezone!
160ms latency 4x increase in performance by installing an opcode cache.
Check not CPU-bound or sitting in io wait state - vmstat 1
Webserver pretty much irrelevant
Single-core gives multiplexing problems so slower on lots of concurrent requests.
Max concurrent requests shouldn't be much more than 5 per core
At yahoo was around 3 per core
Require-once rant. Please listen. Nobody listened in Szeged.
Doing a strace. Lots and lots of opens.
Everything is doing a require-once
So many of them not necessary.
Costs an extra system call and an extra hash lookup
Performance wise not a huge deal unless rung over nfs in which case it's a huge deal
Too paranoid?
DB autoloader doesn't need to ever not be loaded.
Checking for settings, poking around, on every single request. Can we not just hardcode that? Even by default it looks in the wrong place.
A bunch of explodes and implodes
There's a balance between flexibility and performance, always.
"It's for multisite'
I know it's for multisite, but I didn't install multisite. I went through the default installer. It should be able to work this out.
Extra 10ms shaved off - maybe 60ms if NFS.
Original intention in PHP was to do templating in PHP and heavy lifting in C. Most of the world doesn't do that because C is hard. But C is FAST.
Some of the heavy lifting should be moved to an extension.
Someone did it, but only got around 1 percent. But this only implemented two functions. On the list of the two main functions, these were tenth and nowhere.
They get called the most, but they aren't that expensive to begin with.
Xdebug and kcachegrind
Pretty clear it's drupal-render
RINIT and RSHUTDOWN in an extension get called on every single request, whether function actually used.
The drupal-static extension clears functions out of cache table. Can't see why. But we added an extra 0.34 percent by doing this stuff. Hence only a percent saving.
Hiphop
D7 pdo won't work with Hiphop as it currently is.
Few tips. Get APC cache info, because compilation is slow under Hiphop
Get a compiled native executable with a web server baked in...!
Facebook are fixing PDO thing
"they are. Scott said so last week"
He did? Was he drunk?
But this probably isn't going to give you so much
Need to look more at the architecture
Are we using MySQL? Ten milliseconds later... are we using MySQL?
C-based rendering engine for Drupal
"OO attract more developers? Young developers?"
... Don't think it's such a big deal. Features, performance, documentation. PHP is not beautiful. It's about solving people's problems.
"problems with php dev process?"
It's slow. People build what they need. If people aren't personally interested, just doesn't get done. When it doesn't happen, or it's a mismatch, there's frustration. Stop complaining and pitch in.
[isn't this how software projects drift away from being used by non-developers?]
"why shouldn't Drupal move to another language?"
How does the end user benefit? They don't care about the language. They wont to click on the link and they want it to work. That's what they care about.
[suddenly we're back on user focus, not developer focus?]
Gonna take years, with no discernible improvement. Spend time improving the product.
We might get more language agnostic. C based rendering engine. We could then write a drupal module in say Ruby or Python.
"what keeps you excited about PHP?"
I've never been that excited about php. So it's pretty easy to keep that up. I use it to solve problems. If it works, I don't care. I'm not going to be more visible in the community.
I didn't sign up for this twenty-year job. If you want to take over, go ahead.
I think it's still the best tool for the job.
"lambda functions?"
No big deal. Just solves syntax problems. Everyone here spends half their time in Javascript. So you get used to closures.
"do you have a vision for 2020?"
Really hope I'm not standing in front of you guys in ten years.
What I said earlier. Move higher. C. Core of Drupal. Infrastructure you can build around. Flexible. Agnostic
"Did you look at the effect of lots of modules on the site?"
I didn't want to make myself depressed. A lot of modules do stupid things and there's a whole talk in itself in that. The main problems are still in core and we can see them in Xdebug [it sounds like modules have to be assessed on a per-module basis; extra modules themselves are a minor performance hit compared to drupal_render]
