Can "Page's Law" Be Broken?

theodp writes "Speaking at the Google I/O Developer Conference, Sergey Brin described Google's efforts to defeat "Page's Law," the tendency of software to get twice as slow every 18 months. 'Fortunately, the hardware folks offset that,' Brin joked. 'We would like to break Page's Law and have our software become increasingly fast on the same hardware.' Page, of course, refers to Google co-founder Larry Page, last seen delivering a nice from-the-heart commencement address at Michigan that's worth a watch (or read)."

Comments

Of Course

[eldavojohn]

Can "Page's Law" Be Broken?

I think it gets broken all the time. At least in my world. Look at Firefox 3 vs 2. Seems to be a marked improvement in speed to me.

And as far as web application containers go, most of them seem to get faster and better at serving up pages. No, they may not be "twice as fast on twice as fast hardware" but I don't think they are twice as slow every three months.

I'm certain it happens all the time, you just don't notice that ancient products like VI, Emacs, Lisp interpreters, etc stay pretty damn nimble as hardware takes off into the next century. People just can't notice an increase in speed when you're waiting on I/O like the user.

Re:Of Course

[Z00L00K]

The law isn't linear, it's more sawtooth-style.

Features are added all the time which bogs down the software, and then there is an effort to speed it up and then there are features added again.

One catch in performance is that it sure is faster to use RAM for data, but there is also a lot of useless data floating around in RAM, which is a waste of resources.

And this is often the curse of object-oriented programming. Objects carries more data than necessary for many of the uses of the object. Only a few cases exists where all the object data is used. A lot of object-oriented programming is somewhat like using 18-wheelers for grocery shopping.

This often explains why old languages like C, Cobol etc. are able to do the same thing as a program written in C++, Java or C# at the fraction of the resource cost and at much greater speed. The disadvantage is that the old languages require more skills from the programmer to avoid the classical problems of deadlocks and race conditions as well as having to implement functionality for linked lists etc.

Re:Of Course

[AmiMoJo]

OO was never designed for speed or efficiency, only ease of modelling business systems. It became a fashionable buzz-word and suddenly everyone wanted to use it for everything, so you end up in a situation where a lot of OO programs really only use OO for allocating memory for new objects.

I'm not trying to be a troll here, I just find it odd that OO is considered the be-all and end-all of programming to the point where people write horribly inefficient code just because they want to use it. OO has it's place, and it does what it was designed to do quite well, but people should not shy away from writing quality non-OO code. I think a lot of programmings come up knowing nothing but OO these days, which is a bit scary...

Most bang for the buck.

[rotide]

Why would a company spend money to make software more efficient when the current incarnation does its job just fine?

While I like the idea of being as succinct and efficient as possible with your code, at what point does it become fruitless?

Obviously, if you're testing your code on a "new" workstation and it's sluggish, you'll find ways to make it work better. But if it works well? What boss is going to pay you to work on a project for no real benefit other than to point out it is very efficient?

They probably will.

[fuzzyfuzzyfungus]

I'd suspect that Google probably will. Not because of any OMG special Google Genius(tm), but because of simple economics.

Google's apps are largely web based. They run on Google's servers and communicate through Google's pipes. Since Google pays for every server side cycle, and every byte sent back and forth, they have an obvious incentive to economize. Since Google runs homogenous services on a vast scale, even tiny economies end up being worth a lot of money.

Compare this to the usual client application model: Even if the scale is equivalent, the maker of the software doesn't pay for the computational resources. Their only pressure is indirect(i.e. customers who don't buy because their machines don't meet spec, or customers who get pissed off because performance sucks). They thus have a far smaller incentive to watch their resource consumption.

The client side might still be subject to bloat, since Google doesn't pay for those cycles; but I suspect competitive pressure, and the uneven javascript landscape, will have an effect here as well. If you are trying to sell the virtues of webapps, your apps are (despite the latency inherent in web communication) going to have to exhibit adequate responsiveness under suboptimal conditions(i.e. IE 6, cellphones, cellphones running IE 6), which provides the built in "develop for resource constrained systems" pressure.

Re:The 'easy' way

[imgod2u]

The problem there is that there gets to a point where the user just won't notice "stellar" speeds. Take a video game for instance. Anything past ~70 fps is really unnoticeable by the average human eye. If you design the game to run at 70 fps for a slow and memory constrained machine, the user won't really notice his quad-SLI or whatever vacuum cleaner box being any better. And you've sacrificed a lot in visual quality.

Adding RAM to an existing device

[tepples]

RAM is cheap these days.

Unless you would need to add RAM to millions of deployed devices. For example, the Nintendo DS has 4 MB of RAM and less than 1 MB of VRAM, and it broke 100 million in the first quarter of 2009. Only one DS game came with a RAM expansion card.

Re:Page's Law.

[mdmkolbe]

Do you remember Moore because of his law or because he co-founded Intel?