This isn’t exactly a quiz because you couldn’t possibly know the answer unless you were there or are pyschic but it’s a fun result anyway so I thought I’d share.
If you’ve ever read my mini-bio anywhere you’ll know that this is actually my second stint in the Developer Division at MS. My first stint was about 7 years long and ended back in 1995. One of the last things I did then was tune what would become Visual C++ 4.0 — we called it the “Olympus” release.
A big problem we faced in Olympus was that compile times within the IDE were significantly slower than they were if you did the same compile from the command line. It was pretty easy to see that the reason for this was that the IDE was using memory (and doing processing) during the build and so there was less available for the compiler/linker hence a little more swapping and slower builds. My job was to get the IDE’s footprint to be as small as possible.
OK, so here’s the quiz.
The test case is building a simple “MFC App Wizard” default application from scratch on a machine with 16M of memory. How many pages did the IDE use while the build is active after I was done? For bonus points how many of those were code pages? Most people answer in megabytes and divide by 4k to get pages.
The way I did analysis was I sampled the working set once a second for the entire build so I would get numbers for each module. In the interest of typing less (I only have a hard copy of my last report) I will just give the totals rather than the breakdown by module.
|23.88||31||10||–||–||ready to build, ide idle|
|26.91||467||120||157||167||thinking about what to build|
|29.95||31||10||–||–||IDE has launched compiler|
|31.97||43||13||2||7||output, first file done|
|37.03||43||13||2||7||output, second file done|
|42.08||43||13||2||7||output, third file done|
|47.14||43||13||2||7||output, fourth file done|
|48.15||218||10||–||–||IDE thinking about link steps|
|57.25||43||13||2||7||processing linker output|
|62.31||43||13||2||7||processing linker output|
|66.36||192||54||50||65||link finishes bscmake invoked|
|67.37||43||13||2||7||processing bscmake output|
|71.42||43||13||2||7||processing bscmake output|
|74.45||711||234||222||232||IDE returning to normal state|
First thing to note is that the times shown here aren’t “real.” In order to do this experiment I flushed the working set every second (well it ended up being every 1.01 seconds but anyway) and that slows things down a lot. So the true times would be much less (this build took about 15s on that era of hardware as I recall). Also note that the total is greater than the sume of the other 3 columns because it includes system overhead costs as well (like page table pages) that are not broken out.
OK with that in mind you can still see the phases clearly and… while the compiler(s) are running the ide is using either 31 or 43 pages respectively. That’s 124k or 172k. During normal compiler processing ZERO code ran in the IDE for seconds at a time (no code pages were faulted in). Output processing took 7 pages — 28k. Note that 21 of the pages were (nearly) unavoidable system overhead to handle mapping our VM and whatnot.
To get these kind of results we did some pretty careful analysis. One I distinctly remember was that I was seeing a sort of one second “pulse” in the working set that I couldn’t explain. I was staring at my screen trying to think what it could be and then I saw it was literally in my face — the caret was beating at about 1 Hz. So I turned off the caret in the output window during the build and poof the pulsing went away.
Anyway fun stuff.
How did you do? Most people who answer are off by a factor of about 20.