Slashdot Mirror
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)."
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.
My work here is dung.
Page must have been a Java programmer, because Java is slow as hell and it only gets slower.
Make developers target a slow and memory constrained platform. Then you get stellar performance when it runs on the big machines.
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?
It gets twice as bloated.
who are trying to make software be available only via a browser and clunky javascript
makes this rather ironic
1) Historically: thwarting piracy. Bigger apps were harder to pirate. Copying 32 floppies = pain in the ass.
2) The perception of value. More megabytes implies more features implies more value. You can charge more. Also, you can charge people again for what is basically the same product (there are companies that depend on this!)
You just get an app which uses 100k of RAM and 32gb of filesystem buffer.
Deleted
"Page's Law" seems to be a tongue in cheek joke since it's sited primarily by the Google folks themselves. It definitely isn't true across the board. It's purely a matter of a) what the software application is and b) how the project is managed/developed. If the application is something like a web browser where web standards are constantly being changed and updated so the software must follow in suit, I could see where "Page's Law" might be true. But if the product is well managed and code isn't constantly grandfathered in (i.e., the developers know when to start from scratch) then it wouldn't necessarily be a problem.
"I have never let my schooling interfere with my education." --Mark Twain
It only makes sense to improve a compiler, library or application if you're going to be the one USING it. Not the one SELLING it.
If you're selling it then the faster you can get your pile of shit out the door into the marketplace and generating revenue, the better. Hence Java, Ruby etc.
That is... There is an economic incentive to produce bloated slow piles of crap, and little incentive to produce fast, light, efficient systems. It ain't a technical problem, it's an economic one.
Deleted
I wasn't talking about it for a while as I am tired of Google fanatics but, what is the point of running a software with Administrator(win)/Super User(Mac) privileges every 2 hours that will... check for updates?
I speak about the Google Updater and I don't really CARE if it is open source or not.
Not just that, you are giving a very bad example to industry to use as reference. They already started talking about ''but Google does it''.
Is that part of the excuse? Because hardware guys beat the badly designed software coded by some re-invent wheel guys? Does something run in your server farms opening a socket to the outside World every 2 hours that will check for updates?
Listen, people purchasing $1400 software are bugged about their paid commercial software checking for updates yet alone it does only check weekly and _if application runs_. We don't have hardware to waste or some top certified security engineers to waste. Stop thinking everyone has some undocumentedly large server farms like you.
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.
When I was a little kid, I saw a new computing device: a Pacman cabinet at the local pinball parlour.
Since then, I've seen dozens of implementations of it, and they fall into two camps: a knockoff that can hardly be called a Pacman-clone, or a full-up 100% authentic duplicate of the original. Of course the latter is done with emulation. Every important detail of the old hardware can be emulated so a true ROM copy can be run with the same timing and everything behaves properly. If you know the proper secret patterns through the maze, then the deterministic behaviors of Inky, Pinky, Blinky and Clyde will not allow them to catch up to you.
We also have many kinds of indirection, where data must be handed through one protocol to another, in order to reach the intended platform. I'm not just talking about TCP/IP and routers, but many new layers to the OSI layer cake: encryption, encoding, tunneling and translation.
Of course, emulation and indirection can go too far. Imagine playing that ROM copy of Pacman on a MAME built for PPC running on Mac OS X Tiger's Rosetta layer, played through a VNC terminal over SSH via an HTTP proxy. That's a contrived (but perfectly possible) example, but I see layers and layers of indirection in real operating systems and applications all the time.
To break "Page's Law," I expect one should focus on reducing the layers of emulation and indirection.
[
Sounds like someone is trying to cement their legacy in history by stamping their name on common knowledge. :-)
We could also consider the possibility that a twice-as-fast computer on a twice-as-fast network pipe produces twice-as-much data which, in order to keep the same perceived speed, must be processed twice-as-quickly by another computer.
Make developers target a slow and memory constrained platform.
I hope you're not talking about something like the NES. There are some things that just won't fit into 256 KB of ROM and 10 KB of RAM, like a word processing document or the state of the town in a sim game like SimCity or Animal Crossing.
Then you get stellar performance when it runs on the big machines.
Only if the big machines use the same CPU and I/O architecture as the small machines. Otherwise, you need to use an emulator that brings a roughly 10:1 CPU penalty (e.g. PocketNES), or more if the CPU has to translate between I/O models (e.g. NES emulators on PCs).
Actually, if you're doing test-directed development, you should have a test that tells you if you've met your performance needs or not. Your management wants to know they have a certain amount of bang/$, to meet their performance budget.
For user-interface stuff, that could be as simple as "3 seconds on average, no more than 5% over 20 seconds", for some number of simulated users on your development machine.
So build a test framework and measure the first part of the program you write. For example, that might be the front end of an interactive query program. Put in a dummy delay for the back-end database and test performance the first day the code responds to a request. Code and tune to meet your performance targets, and stop tuning as soon as it is fast enough . In this case the tuning will mostly be looking at code-path length with your test framework and a source-code profiler, to get both latency and transfer time down to an appropriate value. Since you have the program available to you, measure the residency times in each major component with the profiler. The slowest component will be the limiting factor, and the limit on its performance will be 1/Dmax, where Dmax = V *S, visit count to the component, times service time for it.
Once the code is performing, now is a good time to stop and look at resource usage. Find out how much CPU, memory and I/O bandwidth your program uses per transaction, and save that information for sizing later. You will need to ensure when you size the system that you dont introduce an artificial bottleneck. This is where your management will want to know the performance, so they can plan to support an estimated number of users.
Returning to tuning, next build a test version of the sql. Run it as a script and measure the sql response time. Now you can tune the database queries, and get them fast enough.
Finally, if your program contains middleware, arrange for it to communicate via sockets, and measure performance at the front end and the database. The difference will be the performance of the middleware. As before, the demand of the slowest component will be the bottleneck, and will hold performance to 1/Dmax. Speeding up other parts of the programs wont help.
Consider this the performance experts version of test-directed design.
--dave
davecb@spamcop.net
One thing that rarely comes up when discussing bloat and slow underperforming applications is energy consumption. While you can shave off some percents off of a server by maximizing hardware energy savings you can save much more by optimizing its software in many cases.
I think it all comes down to economics. As long as the hardware and software industry lives in symbiosis with their endless upgrade loop we will have to endure this. To have your customers buy the same stuff over and over again is a precious cash cow they wont let go off volontarily.
HTTP/1.1 400
From the transcript of the speech:
"you never loose a dream"
Rich And Stupid is not so bad as Working For Rich And Stupid.
It's simple, just don't use Java
In a more serious note, my personal opinion is have the developers use and test the programs in slower machines.
Yes, they can profile the app, etc, but the problem is that it really doesn't create the 'sense of urgency' working in a slow machine does. (Note I'm not saying developers should use slow machines to DEVELOP, but there should be a testing phase in slow machines)
Also, slower machines produce more obvious profile timings.
how long until
Unlike workstations where(as you say) the value of going from "workstation adequately responsive, 60% load" to "workstation adequately responsive, 30% load" is pretty much zero
Not always. A notebook computer running at 60% load draws more current than one running at 30% load. But LCD backlights eat a lot of power too, and the licensing policy that Microsoft announced for Windows 7 Starter Edition (CPU less than 15 watts) might encourage CPU engineers to move more logic to the GPU and the chipset.
If you have thousands of instances, gains of even a few percent mean substantial reductions in the number of servers you need to run.
Moore's law predicts that transistor density on commodity integrated circuits doubles every 18 months. This means more cores can fit on the same size chip. If your applications are inherently parallel (as servers often are), and your user base doesn't grow faster than that, you can just throw more new hardware at the problem. But you do need to optimize in a couple cases:
but I don't want to break any laws.
Deja Moo: The feeling you've heard this bullsh*t before.
Herb Grosch said it in the 1960's: Anything the hardware boys come up with, the software boys will piss away.
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.
Making later versions of software run more efficiently on a baseline piece of hardware may also make the software run more efficiently on lesser pieces of hardware. Does the increase in possible install base (since your software now runs on hardware slower than your baseline) justify a concerted effort to write software that runs more efficiently?
The cancel button is your friend. Do not hesitate to use it.
10.0, 10.1, 10.2, 10.3, and maybe 10.4 was a series of releases where performance improved with each update. I don't run 10.5 so can't comment if the trend continues.
you had me at #!
Hardware has advanced to the point that we don't care about performance all that much.
What is more of a concern is how easy it is to write software, and how easy it is to maintain that software, and how easy it is to port that software to other architectures. Efficiency of code generally means efficient use of a single architecture. That's fine, but for code that has to last a long time (i.e., anything besides games), you want it to be written in a nice, easy-to-change way that can be moved around to different platforms for the next 20 years.
Anything past ~70 fps is really unnoticeable by the average human eye.
I disagree. If you can render the average scene at 300 fps, you can:
If you design the game to run at 70 fps for a slow and memory constrained machine [...] you've sacrificed a lot in visual quality.
A well-engineered game will have (or be able to generate) meshes and textures at high and low detail for close-up and distant objects respectively. On high-spec PCs, you can use the high-detail assets farther from the camera; on the slow and memory-constrained PCs that your potential customers already own, they get the low-detail assets but can still enjoy the game.
I wounder how much energy and money this would save for a server hog like Google. Reminds me of Blackle
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.
Then why are games for PlayStation 2 still coming out years after the launch of the PLAYSTATION 3 console? If the incentive to run on existing deployed hardware were so small, major video game publishers would make their games PS3-exclusive even if the game's design didn't require it.
"Page's law"? Not too egotistical is he? I guess by stating the obvious that make it his idea.
Seriously.... I can count on one hand the can't-live-without software that has changed in the last 10 years.
After those 6 or so Apps, the rest is just candy.
My point is that if you're already paying to replace hardware, your cluster's capacity will grow over time as you do so because the new machines will be bigger and faster than the ones they replace. So if your application's performance is already satisfactory, you need to optimize if and only if you expect load to grow faster than the computing power of your cluster.
Business managers don't want to pay for great when good will do. Have you gotten the beta to compile yet? Good, we're shipping. I don't care if it was a tech demo, I don't care if you said your plan was to figure out how to do it first, then go back through and do it right. We have a deadline, get your ass in gear.
Then the next release cycle comes around and they want more features, cram them in, or fuck it we'll just outsource it to India. We don't know how to write a decent design spec and so even if the Indians are good programmers, the language barrier and cluelessness will lead to disaster.
And here's the real kicker -- why bother to write better when people buy new computers every three years? We'll just throw hardware at the problem. == this is the factor that's likely to change the game.
If you look at consoles, games typically get better the longer it's on the market because programmers become more familiar with the platform and what it can do. You're not throwing more hardware at the problem, not until the new console ships. That could be years and years away, just for the shipping, and even more years until there's decent market penetration. No, you have to do something wonderful and new and it has to be done on the current hardware. You're forced to get creative.
With the push towards netbooks and relatively low-power systems (low-power by today's standards!), programmers won't be able to count on power outstripping bloat. They'll have to concentrate on efficiency or else they won't have a product.
There's also the question of how much the effort is worth. $5000 in damage to my current car totals it, even if it could be be repaired. I can go out and buy a new car. In Cuba, there's no such thing as a new car, there's only so many on the market. (are they able to import any these days?) Anyway, that explains why the 1950's disposable rustbuckets are still up and running. When no new cars are available for love or money, the effort in keeping an old one running pays for itself.
Excellence has to be a priority coming down from the top in a company. If cut-rate expediency is the order of the day, crap will be the result.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
KDE4 is ~30% faster than KDE3, mainly because of the Qt4 vs. Qt3 improvements and vast redesign of the KDE itself...
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
Hardware has advanced to the point that we don't care about performance all that much.
That might be true of software intended to run on desktop PCs. But for servers, you want efficiency so you can handle more requests from more users. And for software intended to be run on small, cheap, battery-powered devices, you want efficiency so you can underclock the CPU and run longer on a charge. You mentioned games, but a lot of applications for handheld and subnotebook computers aren't games.
"Page's law" is simply a restatement of May's law:
"Software efficiency halves every 18 months, compensating Moore's Law".
David May is a British Computer scientist who was the lead architect for the Transputer. See:
http://en.wikipedia.org/wiki/David_May_(computer_scientist)
and page 20 of:
http://www.cs.bris.ac.uk/~dave/iee.pdf
Is a another version.
A supercomputer is a device for turning compute-bound problems into I/O-bound problems.
-- Ken Batcher
I have realized that I will have been working as a dev for ten years now in four days. I've worked at a few places and I think that the reason for this is pretty straight forward, poor benchmarks used poorly.
We have all heard the mantra about optimizing early is evil but there are two issues to contend with. You get to a crunch time towards the end and then there is no time to address performance issues in every project. By that time so much code is written that you cannot address the performance issues in the most effective way, thinking about what algorithm to use in the dataset that ends-up being the common case. So instead some profiling work gets done and the code goes out the door.
So for success you need to have some performance measurements even early on. The problem is that in that case you end-up with some benchmarks that don't measure the right thing (that is what you discover near the end) or you have worthless benchmarks that suffer too much from not being reproducible, taking too long to run, or not giving the dev any idea of where the performance problem really is.
So what ends-up happening is that only after the code base has been around for a while and you get to rev n + 1 is there any real handle on any of this performance stuff. But often what ends-up happening is that project management values feature additions so as long as no single benchmark decreases by more than 2-5% and the overall performance does not decrease by more than 15% compared to the pre feature build, it gets the okay. Then a milestone arrives and there is no time again for systematic performance work and it ships as is.
The right approach would be at that stage to not allow a new feature unless the overall benchmark does not improve by 2% and to also benchmark your competitors as well but that just does not happen except in the very rare good groups sadly.
"Separate and distinct", not "careful and circumspect".
The transcript leaves out a few things from the video, the main one being that Brin gives a list of applications he has specifically in mind: gmail, chrome, and Native Client. Of these, only gmail is a javascript application. Chrome doesn't run in a browser, Chrome is a browser. And Native Client is an attempt to get out of the very situation you're complaining about, where web-based apps have to be written in javascript. NativeClient (NaCl) is a browser plugin that allows native x86 code to run in a browser. If you read the paper on NaCl I linked to above, the emphasis on security is impressive. They clearly understand what a disaster things like ActiveX have been in terms of security, and they're serious about making it safe with all kinds of fancy techniques.
A couple of other observations:
They're not kidding about making performance a priority, it's not a new priority for them, and they seem to be doing well at it. When I first tried the Google Docs spreadsheet, its performance was completely unacceptable. A year or so later, it was mentioned on Slashdot again. I was all set to make a snarky post about its poor perfomance, but then I stopped and decided to try it again to see if the performance was still as bas as I remembered. It was much better, so I posted on Slashdot to say so. I then got an email from one of the developers working on Google Docs to say he was glad I'd noticed the improvement, because it had been their main priority recently.
In the video, Brin refers to "Page's law" as the "inverse of Moore's law." I would actually say it's not so much an inverse of it as a corollary of it. Developers are always going to be as sloppy as they can get away with being, and they're always going to prefer to work with languages and APIs that give them the maximum amount of abstraction, platform-independence, and expressiveness. Software houses are always going to market proprietary software based on features (which the user can read about before making a decision to buy), not on performance (which the user can't test until he's paid for the software and tried it out on his own machine). Therefore they're always going to write software that performs as badly as they can get away with. That means that if Moore's law improves hardware performance by a factor of x over a certain period of time, software developers are just naturally going to write software that performs worse by a factor of x over that same period of time.
The really scary thing about browser-based apps, in my opinion, is that they represent a huge threat to open-source software, exactly at the moment when the OSS software stack is starting to be pretty comprehensive, mature, and usable. If you look at the web apps out there, essentially all of them are under proprietary licenses, and nearly all of them are impossible to run without a server running the completely closed-source server-side code. Although Google generally seems pretty friendly toward OSS, I don't really want to have to rely on their good intentions. They are, after all, a publicly traded company, whose only reason for existing is to maximize returns for their shareholders. From this perspective, NaCl is actually pretty scary. The default with javascript is that at least you get to see the source code of the client-side software, even if it's under a proprietary license; I think it's only natural for me to demand this if my web browser is going to run random code off of some stranger's web site. With NaCl, the default will be that all I ever get to see is the object code of the program. This is even worse than java applets; java is actually relatively easy to disassemble into fairly readable source code. (And in any case, java applets never caught on.)
Find free books.
... isn't software v. hardware, but speed v. functionality, i. e., in the history of most software, the decrease in speed is disproportional to the increase in functionality. Of course, "disproportional" is subjective, and new, advanced functionalities are generally more complicated and resource intensive than old, basic ones. So a simple reverse-linear relationship might be unrealistic, but when many software don't even manage to beat the reverse-quadratic ratio, there's definitely something wrong.
i run tiger on clamshell ibooks (300-466mHz) w/320-576mB and it's usable, if not always pleasant...otoh, 10.4 on a 400mHz g4 powermac w/agp graphics & 2gB is barely tolerable...
but it's getting harder to keep apps updated: vlc's latest 1.0rc2 sez
Support for Mac OS X 10.4.x was dropped due to its technical limitations :-(
And the easiest way to do it is make Visual Studio (or your compiler and IDE of choice) faster. If Visual Studio is fast, developers won't feel the need to upgrade their machines, and so do not need to perpetuate this cycle.
I'm actually surprised how many folks are doing scrum and test-directed development. I did a year with a group in a relatively boring part of the industry (services) and found that they were heavily into scrum/sprint, java, perl and xml.
They were quite open to adding a trivial performance test to the regression-test suite, just to be sure they didn't accidentally slow it down.
--dave
davecb@spamcop.net
The problem is performance creep. Its easy to find big slowdowns with regression analysis, but you get perhaps as much a 5% variations in timings just depending on the phase of the moon. So any slowdown less than, say, 5% is not discernable from noise. As a result your performance can deteriorate by a few percent per checkin. Over a year that can mount up.
So you have to combat this by actually tuning the software every so often - say once per release - to recover the creep. And, of course, after you do this a couple of times, it gets harder to knock hot spots on the head and you have to do it early in the release cycle as you have to start rearchitecting to actually make a difference.
Squirrel!
It's already broken. Microsofts software gets twice as slow every 9 months.
http://en.wikipedia.org/wiki/Wirth's_law
Camfrog. When it was version 3.2, it was just a 4 meg download. Now it's version 5.3, it's nearly 11 megs, and there hasn't been much of any improvement at all. In fact, it runs WORSE, crashes mroe often, and the only thing they did was add the ability to put stupid eyes over your face and a few shiny UI improvements.
Page's Law will cease to be a law when A. Software/code patents are invalidated and B. programmers, thus free from the nonsense of software/code patents, code as efficiently as possible.
After all, some random programmers can make a fully 3D game in 64KB of code. Why can't 'professional' programmers do the same thing for their video chat programs, huh?
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
I'm constantly explaining to junior devs how to use indexes and other performance features, but the basics of measure, test, measure seem to be lost on all of them. Where is the scientific method in CS these days?
"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" - by Z00L00K (682162) on Monday June 01, @09:24AM (#28166975) Homepage
True! Because, iirc? For every object you instance, it's an added 472 bytes of memory used by said object, @ least in Win32 PE environs (such as Microsoft & Borland compilers (I prefer the latter, Delphi being my fav. even to this very day).
NOW - Though that might not seem like a lot, you have to consider that the gui alone is probably composed of N objects, & whatever classes you make full-blown objects will be adding additional overheads, per each one created.
(Plus, Hey - I don't need an object-oriented design to do a "Hello World" level (meaning simpler/smaller) program: Procedural programming does the job nicely!)
APK
What a pathetic attempt to get known like Moore.
It's not true.
In effect they are saying no software gets faster when the number of transistors within a specific area doubles.
Stupid.
The other side is "When adding more features software has more to do!" No. Shit.
How much work is being down? THAT'S the only relevant metric.
Google has clearly peaked.
The Kruger Dunning explains most post on
def'n: Ascribe your name to some ambiguous phenomenon with barely enough repeated occurrence to be defined and immortalize yourself in the annals of internet history. If your code is getting 2x as slow every 18 months, you need to pursue a new career.
I swear to God...I swear to God! That is NOT how you treat your human!
I honestly dont think so...
Unless you have monkeys mindlessly adding features until the HW grinds to a halt. Then they discover backspace button and cycle repeats.
"Wirth's law" is more quality related, as in "crappy SW can benefit from faster HW".
"Gates's Law" is user-side observation, "speed of commercial software generally slows by fifty percent every 18 months thereby negating all the benefits of Moore's Law".
"Page's Law" is reflection on SW development of a single company: "software gets twice as slow every 18 months... Google plans to reverse this trend and optimize its code."
I wonder if anyone else noticed these differences.
Vista can aggressively cache *and* leave resources to user programs.
Caching is retaining resources obtained from a slow source medium in a higher speed medium after an initial request.
What Vista does is fill your RAM with stuff it thinks you're likely to use, in a background thread when your computer is idle. Thus it takes none of your (the user) time.
Nope. Not the same thing. That's precaching. A precache patch to Linux was rejected precisely because people noticed the same sorts of things Microsoft Vista users are complaining about.
The issue with precaching is lets say the operating system decides to load /usr/bin/emacs into pagecache, just because I might use it. Now, since I'm an XEmacs user that's all wasted pagecache space and the time it took to load it. Background or not, it consumes system resources.
I do want large data files, particularly obtained via NFS to be cached as long as reasonable. That's a typical work use case.
My two most frequently loaded apps are World of Warcraft and Mail.app. In neither case do I want those loaded at system boot or at any other time that I have not selected them to be loaded. WoW is for play and I want it to reside quietly on disk when I'm doing something else. Mail.app I only use when I'm connected to the company VPN. There's an idiot MSEXCHANGE server behind it, so a few seconds loading time doesn't impact the sync time once its loaded.
I certainly do not want NeoOffice precached because even though it's kind of slow to load, it's usually wasted space because I only ever need to use it once a week or so.
If Microsoft Vista is really doing precaching not caching, then perhaps you should listen to your users screaming out in pain.
The only real crime is that every other OS doesn't do the same thing.
Whatever. Linux doesn't do it because it causes performance issues. Precaching != caching. Linux, Solaris, Mac OS X seem to be pretty good at caching things people want to have cached. Or to put it in other terms, you have "invented" something that has been rejected as inferior technology in the Unix world. Can you guys please take out a software patent on it? Thanks.
Caching something that will never be used again will eventually correct itself. Precaching something that will never be used is a total waste of system resources.