jducoeur

(Only interesting to programmers, and this time really only interesting to folks who actually build front end pages. But really interesting for those of us who do that.)

Okay, I'm probably late to the party here, and the serious front-end people already knew about it, but last week Otto Chrons (one of my fellow Scala.js geeks) happened to point to an article that mentioned Chrome's current Performance tab. So I took a look, and found it downright revelatory. That turned into the focus of this weekend's Querki release.

If you have Chrome, go check it out: Inspect a page, go to the Performance tab, and reload the page. Poof, you are presented with a wonderland of data. Here is a representative image from Querki, behind the cut tag. (Ignore the nonsensical function names -- that's because the code has all been optimized.)

( Read more... )

At the top, it shows a summary of what the CPU was doing while you reloaded. This makes it starkly obvious when the page is just sitting there, waiting for stuff from the network. Below that is a sort of icicle view of exactly what happened when, with each task broken into sub-tasks, and sub-sub-tasks, and sub-sub-sub... you get the idea.

Honestly, it smacked me across the face: it turned out that one reason Querki's page load was so slow nowadays was that it was taking over two seconds to parse a bloody text file, because I hadn't optimized the parser properly. An hour or two of hacking on that, and I'd reduced it by over 80%. Check.

Then there is all that downtime: basically, it would completely lay out the basic page, then go fetch the big scripts, and only once those fed in did it start to process. This led to me reading into the new Preload tag. This is very new (as in, it's been around for about a year), and only supported on Chrome and Opera, so it's not a panacea -- but it does help a lot of the market. Basically, it lets you say "I am going to need this resource soon, so start loading it Right Now". If it's supported by the browser, and you have enough network connections, it starts fetching it in parallel, so the scripts can start to execute as soon as things are ready for them. That seems to shave another second or so off of load time.

Overall, it's a huge win, and the result is that Querki's initial page load is now down from averaging about 6-7 seconds on the desktop to sometimes getting as low as 2 seconds under optimal circumstances. (Among other things, this means that navigating to your index and then over to another Space is much faster than it had been.)

I haven't managed to fix everything yet: there turns out to be another fetch that is sometimes causing delays, which Preload doesn't seem to work on. (Basically, because it's an AJAX request.) That's going to need a serious rewrite, I think. But I hadn't even realized it was a concern until getting whapped upside the head by the Performance tab.

So to summarize: if you're building webpages, Chrome's Performance tab is your friend. It's dense, but chock-full of useful information to help you understand exactly what's taking how long at load time...

Fact: I slept poorly last night. (No particular reason, just restless.) Hence, I am very tired today.

Fact: I am being considerably more productive today than usual.

Theory: this seems to be mostly because I just plain don't have the energy to overthink and doubt my previous decisions, so I'm just building the system as designed.

There is a lesson in here, somewhere...

This week's adventure in conferencing is my first trip to ScalaDays, which is in Chicago this year. This morning's keynote was a bit surprising, because it was about the language Rust, rather than Scala. But it was a great talk, and very educational -- I've known vaguely of Rust for a while, but really hadn't known the details. Here's a summary of what I learned, but I recommend checking out the video of the talk once it comes out.

I've been a serious evangelist for Scala for a number of years -- my usual take is that it is currently the best language for general, high-level application programming. You can argue the point, but I'm confident about this one: it's a lovely mix of pragmatism, power and principle, and makes programming more efficient and safe.

But -- not all programming is high-level. Some code needs to be closer to the bare metal, for efficiency, access to the hardware, or other reasons -- it needs to be specifically low level. Scala is only now beginning to be able to do this (with the relatively new Scala-Native compiler), and it's yet to be proven in that environment. Rust, on the other hand, is designed for that world from the get-go.

Or to put it another way, Rust is to C++ as Scala is to Java: a much newer, rethought, more powerful and safe language for playing in that domain.

The core problem with low-level systems programming is that it is scary -- it is very easy to commit any of several major mistakes, each of which leads to crashes or, worse, security leaks. This is true even if you're good at this stuff: programs are complex, and the interactions between the parts are where the bugs tend to arise. Rust is all about reducing that fear, and letting you code with confidence.

The beauty of Rust is that they've taken a very principled look at where those problems tend to come from, and found a few key areas to improve. In particular, the observation is that many bugs arise from uncontrolled access to memory. Plain and simply, pointers are a problem.

So Rust's biggest innovation is removing that word "uncontrolled". It introduces a compiler-time notion of "ownership", and distinct notions of mutable references (which give a code block the right to alter that memory block) vs "shared" references (which allow you to inspect the memory). While they don't use the same terminology, the concepts appear to be quite similar to write vs read locks in database programming.

They've built a lot of infrastructure on top of that, with some really remarkable results. Perhaps most impressive, they've built a concurrency framework that manages to be both flexible and safe. Most of the standard patterns for concurrent programming exist, but they're all adjusted to this ownership-centric world, such that many of the common race-condition problems just can't arise unless you explicitly say "yes, this code is cheating -- I know what I'm doing".

It doesn't solve every problem -- I checked after the talk, and confirmed that it's totally easy to cause deadlocks (unsurprising, given how much this looks like database programming) -- but it's still beautiful and powerful. In the area of concurrent programming, Rust is arguably better than most high-level languages.

Overall, I'm impressed, and I'm pleased to see Rust being presented at a Scala conference -- it looks to me like the languages are nicely complementary. Rust isn't really in competition with Scala: it is optimized for different kinds of problems. But it is principled, and well-designed, in a way that is very reminiscent of Scala. The combination of Scala for application-level programming with Rust for systems and components provides a solid replacement for the older Java/C++ stack.

Not that I've done much systems programming in the past 15 years, so I don't know if I'm likely to use Rust any time soon. But it's good to see the rise of a language that doesn't suck for that domain. God knows, my life 20 years ago would have been much happier with it...

This one's just for the programmers/architects, and mainly for the experienced ones: Things I Wish I Knew When I Started Building Reactive Systems.

The more you're used to building traditional Tomcat-plus-RDBMS applications, the weirder you're going to find this, but it's well worth reading and absorbing. It describes a few of the assumptions underlying modern, scalable, so-called "reactive" architectures, each of which gores one of the traditional sacred cows you're probably used to. What it all boils down to is that it's entirely possible to build seriously efficient, seriously scalable online services -- you just have to change a lot of well-worn habits.

(Querki is built around all of this stuff, except that I still have some blocking I/O in the MySQL code; replacing that with a better approach such as Slick is becoming an increasingly high priority.)

And this reminds me: among other things, it links to the paper Life Beyond Distributed Transactions. If you're playing at the Senior Software Engineer or above level, this is one of the most important papers of recent years, and you should read it if you haven't already done so. It was the paper that finally demonstrated that the emperor has no clothes: that the traditional transaction-oriented model of data processing doesn't scale well, and that you need better approaches if you're going to compete in the modern world.

For all that it calls itself "An Apostate's Opinion", it has become something like the new gospel. It has inspired enormous ferment and evolution over the past decade, and led to radically new architectures (such as the event-sourced approach that Querki is now mostly built on). If you are doing architecture for systems that are intended to scale, you need to understand this stuff in order to understand how the industry is evolving...

The Uncertainty Principle: you can fully understand your feature set or your schedule, but never both. The more precisely you try to understand one, the less confidence you can have in the other.

The First Law of Project Motion: the more precisely you attempt to understand the full scope of the project, the more inertia you add to it, and the more slowly it will move.