These postings are provided "AS IS" with no warranties, and confer no rights. Use of included code samples are subject to the terms specified at Microsoft -
Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
Like many places we’ve spent the past few weeks under quite a bit of snow, which is pretty unusual for Seattle! Most of us on the team took advantage of the snow time to install test builds of Windows 7 on our home machines as we finalize the beta for early 2009—I know I felt like I installed it on 7000 different machines. We’re definitely looking forward to seeing folks kick the tires on the beta when it is available. For more information on the beta, please stay tuned to http://www.microsoft.com/windows/windows-7 which is where we will post information about participation.
This post is about a Windows 7 feature that covers a lot of territory—it is about networking, user interface, sharing, media, printing, storage, search, and more. HomeGroup is a way of bringing all these features together in a way that makes it possible for a new level of coolness in a home with multiple PCs running Windows 7. A lot of us are the sysadmins for our own homes and for many others (friends and family). We set up network topologies, configure machines, and set things up so they work—HomeGroup is designed to make that easier so it can be done without a volunteer sysadmin. It makes for some challenges in how to describe the feature since the lack of such a feature has each of us creating our own private best practices or our own techniques for creating and maintaining a home network. HomeGroup is about making this easier (or possible for everyone else) and at the same time giving you the tools to customize and manage—and no matter what, under the hood the file and printer sharing, media sharing, and networking you are already familiar with is there should you wish to stick with the familiar ways. HomeGroup is a deep feature that builds on a lot of new infrastructure/plumbing new to Windows 7, though in this post we’ll talk about it from the experience of setting up a network.
This is a feature that is one you should just use and see it working, rather than trying to read about it as it covers so much territory in writing.
This post is by Jerry Koh a lead program manager in the Core User Experience team, with help from a number of folks across the dev team. --Steven
PS: From all of us on the Windows team, we wish you a very Happy New Year!
You probably have seen or heard about HomeGroup by now. We demonstrated it at PDC this year during Steven’s keynote, it was mentioned a few times at WinHec, and some of you may have even tried it on your PCs with the PDC pre-beta build of Windows 7. HomeGroup represents a new end-to-end approach to sharing in the home, an area in which Windows has provided many features before --- the intuitive end to end is what’s new. HomeGroup recognizes and groups your Windows 7 PCs in a “simple to set up” secure group that enables open access to media and digital memories in your home. With HomeGroup, you can share files in the home, stream music to your XBOX 360 or other devices, and print to the home printer without worrying about technical setup or even understanding how it all works.
This blog post is designed to give you a behind-the-scenes look at how we designed HomeGroup.
The HomeGroup design goal, like other Windows 7 features, is informed by customer data and input. Whether from the Customer Experience Improvement Program (CEIP), the Windows Feedback Panel, focus groups or usability sessions, the data we collect enables us to focus on key areas where people feel the most pain. To begin figuring out how to solve file and printer sharing problems in the home, we started by looking at how people interact within a home environment. We wanted to learn not only how people used computers in the home, but also what social and behavioral norms were acceptable to see if there were parallels that we could bring into our design. We found the following:
The social model of the home also reflected how people want to share. When we discussed file and printer sharing in the home (or the concept of doing so), we found that people classify their content generally into four different buckets: private, public, parentally sensitive, and children’s stuff. Private content consists of business and financial data and is considered private mainly because people fear it will be accidentally deleted as the number of people who have access to it increases.
People are typically quick to point out that they don’t have entertainment content they consider private, and they’re very open to free access to this content within the family. Families with children are often concerned about parentally sensitive content (inappropriate music, videos, etc.). With digital cameras and camcorders dropping in price and being widely adopted, parents are primarily concerned about accidental deletion or loss of original copies of digital memories.
These observations were very interesting to us; a model that mirrored real-world expectations for sharing could be more natural to people than something that layered different questions around security, permissions or rights. So we approached the HomeGroup sharing model with the concept of open access in the home. But, how can we define what the “home” really is? What assumptions can we make about security?
One of the key advances we’ve had in home networking technology has been wireless. Standards like 802.11 have taken the home network by storm. Wireless router sales to consumers are higher than ever, and are projected to continue growing. As a wider segment of people buy wireless routers, concerns about security start to build up. When configured incorrectly, wireless networks can leave your entire home network vulnerable to malicious people or nosy neighbors. While there have been efforts to help people become more aware of securing wireless networks -- such as the “Windows Rally program” and various “Windows Connect Now” technologies--the general public still lags behind in setting up security for their wireless networks. We know from our customer data that more than half of all wireless networks, whether by choice or oversight are set up as unsecured and we know many of you are the first line of defense in helping your friends and families set up a secure home network. While trends all point to more awareness and improvement in the future, it isn’t clear whether we would ever reach 100% security on these networks. So how can we make sure home networks are secured?
Another interesting factor is the usage of passwords on user accounts in the home. While people are more sensitive to security than ever before, we also observed that many don’t want to set up passwords for their Windows user accounts. They feel that it is a barrier to their use of the computer and yet another thing for them to remember or lose (as an aside, passwords are often viewed as a performance bottleneck in the home). From the data we obtained from the Windows Feedback Panel, a majority of users actually don’t use passwords in the home, opting for the simple model of opening the laptop lid and using Windows quickly. This parallels usage patterns on cell phones, where setting passwords on them would just be a deal-breaker for most people.
A majority of the computers in our panel only had one primary user. While we all know that laptop sales have overtaken desktop sales in the last couple of years, this data tells us that people are buying PCs more for specific people rather than for a shared location. With laptops, the mobility factor has contributed to the “one person/one computer” landscape, again mirroring cell phone ownership patterns in which users almost never share a personal cell phone. Clearly as notebook options include even less expensive options, this will only increase, though we recognize it is still rather a luxury in most of the world.
So we wanted to find a model that could secure home sharing for people who don’t use passwords and could also take into account the more personal nature of PC usage.
First we needed to figure out that people were “at home”. Luckily we didn’t need to look very far for some useful technology in this area. Windows Vista introduced a concept known as network location awareness (NLA). This enables the system to recognize when you’ve changed network locations, and it tags the location with a simple “Home”, “Work” or “Public” designation. While it was somewhat of a mystery in Vista in terms of what such a designation did (unless you read all the words), we will see the infrastructure has become increasingly important as we built out the HomeGroup scenario. In addition to ensuring the right firewall settings are configured for these locations, NLA also enabled us to be smarter about starting Windows services that are targeted at specific network locations. For example, the network discovery service does not start if you’re in a public location. However, Windows Vista didn’t have much distinction between the “work” and “home” network locations; they were essentially the same in terms of which firewall ports were opened and which Windows services were started.
In Windows 7, we extended the concept of NLA and made “work” and “home” more distinct. In Windows 7, when you select the “home” network profile, we know that you are “at home”, and will start the essential services required for successful file and printer sharing in the home. This provides an intuitive entry point into HomeGroup, and once you are “at home” we start looking for (via network discovery) other Win7 PCs in the home. If you already have a HomeGroup active, we offer you the ability to join it; if not, you can create one.
Now that we know your PC is at home, we need to make sure that your data is secured from prying eyes. While wireless security is full of acronyms and technical solutions to security (WEP, WPA, TKIP, etc., to name a few), the fundamental model of wireless security is fairly simple for people to understand. The use of a physical key (copied several times) to enter one’s home is mirrored by the concept of typing in a shared key to gain access to the home wireless network. In the HomeGroup case, Windows will provide you with a pre-generated password out of the box, which you would hand over to any member of the home, and they could then join the group.
While a password is provided by default, people can, at any time, visit HomeGroup in Control Panel to change their password to something they prefer. This flexible system performed very well in testing. When faced with the default password, people wrote it down, and shared it with others to set up the HomeGroup. You may ask, why don’t we enable people to set their own passwords by default? The answer is actually quite ironic, since that was our initial design. In testing, this concept raised quite a bit of alarm with people. It seems that most people generally have 1 or 2 passwords that they use for all their online or offline activities. When asked to input a user password for their HomeGroup, they gravitated towards using one of those, and then reacted with alarm when they realized that this password needs to be shared with other users in the home! People generally reacted better to the auto-generated password, since they knew to write it down and hand it around. The other interesting benefit we got from this was a reduction in the amount of time people would spend on the UI that introduced them to the HomeGroup concept. With a user-generated password, they had to grasp the HomeGroup concept, think about what password to set, and decide whether to accept the shared libraries default. Without having to provide a password, people had more time to understand HomeGroup, and their sharing decision – leading to a much more streamlined, private, and secure design.
In addition to balancing security with ease of use, we also wanted to account for PCs becoming more personal. For this reason, we adopted the concept that each person in the HomeGroup is a peer of the others. Each person can thus join and leave the HomeGroup as they wish. Each person brings with them their choice of media/memories or files to share with the rest of the home. With a system based on equals and peers, the big benefit is a lack of management overhead; you don’t need one person to bear the management task of maintaining the group and dealing with membership tasks. This eliminates a primary source of complexity. All you need to gain entry is the shared password (just like the house key that each family member has).
With a home full of equals, what would they share? As mentioned above, our customers indicated a desire to share media, both music and photos, they want to quickly and easily access within the home. So that is exactly what we implemented. HomeGroup will enable sharing the pictures, music, and video libraries from your Windows 7 PC by default. Another blog post will go into more detail on how libraries work, but in a nutshell, they provide Windows with a way to aggregate multiple physical locations on a computer into one unified view. This is a very powerful addition to the way you organize your data in Windows. Your Pictures library can now contain your <username>\pictures folder, the Public\pictures folder, as well as the f:\foo folder that contains other pictures (and perhaps is on a USB external hard drive). Viewing your picture library locally gives you a unified view of all the pictures in these locations and enables you to search, sort, and organize them in the same way you would within a folder, while also making sure you save new items to the right place physically.
In addition to media, some people might want to share their documents. We enable you to do this when you create or join a HomeGroup. This is great for people who want to collaborate with their family or in families where open access to documents is not a concern. The content is shared as “read-only” and can be selectively changed in Windows Explorer. We want the system to work the way you expect it to, with enough flexibility to do whatever you want later.
Now that we have made it easy to set up, the next step is to make it easy to use. There were two aspects here that we want to emphasize for this post:
In Windows Vista, this discovery was done through the network folder, which provides a complete, but highly technical, view of the resources available to you on the network. In addition, the network folder also contains other devices and additional media libraries that were shared on the network. This was confusing and difficult to understand for typical people. For example, if you shared your Pictures folder, it was actually found under the computer in \\<computername>\users\<username>\pictures. Typically, people would not know to look into that path for the correct folder.
The concept of “libraries” introduced in Windows 7 gives us the design point to improve access their content across the network. While libraries aggregated the view on a local computer, if these locations were shared out to the network, they resulted in a more complicated view in the network folder for our users. Each location would be shared as a separate path, so taking the example above, sharing out the Pictures library means that you’ll see three shares under \\computername, Users\<username>\pictures, Users\public\pictures and foo. People would not benefit from the power of libraries on a network. Therefore, we use the concept of libraries to work well even across a home network. We did this in two ways.
First, people should have the same experience viewing a library whether on a local computer or across the network in a HomeGroup. We made sure that when you share the Pictures library in Windows 7, not only are all locations of the library shared, but the library resource is also shared and can be consumed by other computers in the HomeGroup. Effectively, members in a HomeGroup would see just one unified library with its aggregated views.
Second, we found that accessing these resources in the network folder was too many clicks away and sufficiently buried such that people would find it impossible to discover. So we created a new HomeGroup node on the navigation pane in Windows Explorer. When you join a HomeGroup, other HomeGroup Win7 PCs will appear under the HomeGroup node in the Windows Explorer navigation pane. They’re one click away and always at your fingertips. In our tests, this really opened up discovery and usage of content throughout the HomeGroup. People easily discovered music on another computer, played it back, or looked at photos. Consumption of media thus becomes something easy and habit-forming in the home, all by joining a HomeGroup.
With the introduction of libraries, we also had an opportunity to remove some of the confusion between specialized media libraries that are created by Windows Media Player (WMP) or Windows Media Center (WMC). In previous versions of Windows, WMP would scan the entire hard drive on the computer to find media files and add them into a media library, but in Windows 7 this no longer has to happen. Since you already have Windows Explorer libraries, WMP and MCE just use those. If you add new locations to the libraries in Windows Explorer, WMP and MCE now automatically just pick them up since they are using the same common library for the content. We thus eliminated the need for people to manage multiple views of their data using different user experiences. In addition, WMP will also show the media libraries shared by the HomeGroup as nodes in the WMP navigation pane, mirroring the discovery and access model of Windows Explorer. So the same set of HomeGroup users you see in Explorer by default will also be shown to you in WMP as well.
Similar to WMP, in WMC, there is a new “shared” section when browsing media like recorded TV, pictures, music and video. HomeGroup computers show up in this section and can be accessed easily. The content of those libraries that have been shared with the HomeGroup will show up and be accessible in WMC. This includes music, pictures and videos, but also recorded TV--which means that you can now browse and stream non-DRM TV (that was recorded on another computer in your home) from your laptop!
In addition to sharing out your media by default, we also wanted to make sharing additional content to the HomeGroup simple. In the past you had to worry about setting access control, as well as managing user passwords to make sharing work in the home. As we better understood how people interacted and worked at home, we realized that most were OK with enabling general access to all members of the household. So we built a few shortcuts into the sharing experience to enable this. Windows Explorer now features a new “share with” menu in the command bar:
This enables you to select a library or folder and quickly share it with the home. It even enables you to make content writable by home members with one click, thus making it easy for people at home to easily collaborate on pictures or documents. This enables scenarios like importing digital photographs on one computer and editing them on another computer without making a copy. Once you share a folder with the home, it also shows up under the user in the HomeGroup node. This makes it incredibly easy to share anything on your computer to others in the home, and have them easily find and use them. We also recognize that some people need a way to easily bring some of this content off the network quickly and easily and make it private. The “share with” menu includes a shortcut to “share with nobody.” This option removes access to any content that has been previously shared and makes it private, thus enabling us to deliver on another requirement we observed people have in the home.
So what about devices? We’ve heard from you that sharing printers needs to be much simpler. While we have made it super easy to add printers to Windows, we needed to bring this simplicity to the home network. USB printers are still tied to a specific PC and can’t be shared out very easily. People typically email files to themselves to retrieve on another computer, or use USB keys to move their files to the computer with the printer. That had to change.
In a HomeGroup , if you have installed a USB printer that has a Windows logo, the other people on the HomeGroup would get this printer automatically installed on their computers. They won’t see a prompt, they won’t need to answer any questions – it would just show up, and “just work.” For non-Windows logoed printers, we need to ask the user for permission to install the printer. HomeGroup members will see a prompt that a printer has been found in the HomeGroup. Clicking on this prompt installs the driver. The reason we had to do this was to ensure that users consent to 3rd party code that hasn’t been through the rigors of the logo program. One of the big benefits of this system is that you no longer need to find, download, and install the driver manually on multiple computers. The driver (for the correct architecture) is just copied from the computer that has the physical printer attached. This saves time and network bandwidth. With a HomeGroup, there will no longer be a need to think about sharing a printer. If you attach one to a computer in the HomeGroup, everyone else will get it installed and ready to use.
In addition to printers, devices like photo frames, game consoles (such as the Xbox 360), and media receivers (like the Roku Soundbridge) can benefit from some of the easy setup, as well as all the shared media in the home. For setup, we have reduced all the UI within Windows that deals with these devices to one simple checkbox:
Once you are part of a HomeGroup, we turn on Windows Media Player streaming support, so not only will your computer detect other WMP libraries on the network and allow playback from them, devices would also be able to consume the shared media content. Another blog post will go into more detail on an exciting new feature called “play to” which would also be automatically enabled in a HomeGroup enabling you to send media from your PC to any supported picture frame or media receiver, and never have to deal with the minimal UI you have on these devices, which you can see in the demonstration of the Day 1 keynote at WinHEC. If you check a box in HomeGroup in Control Panel, all existing and future devices in the home will detect and consume the media on the HomeGroup computer. All these previously complicated settings are now simplified with HomeGroup.
The laptop buying trend doesn’t stop at home. Large corporations are also moving toward buying laptops for their employees. There is research out there that outlines productivity improvements with employees using laptops. This makes sense as most of these laptop-wielding employees bring their computers home and put in those extra email hours. However, most corporations require that their laptops be joined to a corporate domain. This enables system administrators to manage and maintain these computers. Domain-joined laptops are thus subject to more restrictions than regular home computers are. It’s hard to even locate another PC on the home network to access or share files, let along configure your domain-joined computer to print to a printer at home.
With HomeGroup, we wanted see if we could make things a little easier for these computers to come home. With more and more people working from home or having the option to these days, we wanted to see if they could enjoy some of the media content they have on the other PCs in the HomeGroup while they work. So in Windows 7, your domain-joined computer can join and participate in a HomeGroup. This enables the domain-joined computer to consume the media available on Windows 7 PCs in the home, watch TV through WMC, listen to music via WMP, or print to the printer on another HomeGroup PC all by entering the same key you provide to other computers in the HomeGroup.
The only difference is that sensitive content on the corporate laptop is never shared to the other HomeGroup computers. In essence, the domain-joined computer can see out (and consume) but no one can see in. We believe this meets the need for corporations to maintain security over documents while enabling our customers to enjoy a fun and interesting work environment at home, with access to all their media and home printers while they work. All you need is an existing HomeGroup, a domain-joined computer, and you can be rocking to your favorite tunes on your home network, while you catch up on all your important work.
Of course the ability to join a HomeGroup is a policy that can be managed by corporate domains as you would expect.
Phew! I hope this post has given you some insight into some of our design decisions, as well as the capabilities of the feature. HomeGroup will highlight some of the cool capabilities Windows has had for a long time in a friendly and easy fashion and also build on some of the new plumbing and infrastructure in Windows 7, and we are very excited with its possibilities. It is important to note that none of this would be possible without the help of people around the world who have provided us with opportunities to listen to their feedback, observe their actions, and take note of their needs.
We know there will be lots of discussion around this feature once folks have had a chance to explore it. It represents a new model for something that has arguably been very difficult to set up and so for most people seeing all this work will be a first and for many of us reading this blog we’ll be “mapping” our existing model to this new experience. The best thing to do is just see if you can let Windows 7 run and do the work. After some use you can then dive into the customization and configuration available to you.
To set up a HomeGroup you will need to install Windows 7 Beta on more than one PC on the same network and be sure to select Home as the network location if you want to automatically create (or join) a HomeGroup.
We've talked some about performance in this blog and recently many folks have been blogging and writing about the topic as well. We thought it would be a good time to offer some more behind the scenes views on how we have been working on and thinking about performance because it such an interesting topic for the folks reading this blog. Of course I've been using some pretty low-powered machines lately so performance is top of mind for me as well. But for fun I am writing this on my early holiday present--my new home machine is a 64-bit all-in-one desktop machine with a quad core CPU, discrete graphics, 8GB of memory, and hardware RAID all running a pretty new build of Windows 7 upgraded as soon as I finished the out of box experience. Michael Fortin and I authored this post. --Steven
Our beta isn’t even out the door yet and many are already dusting off their benchmarks and giving them a whirl. As a reminder, we are encouraging folks to hold on benchmarking our pre-production builds. Yet we’ve come to expect it will happen, and we realize it will lead many to conclude one thing or another, and at the same time we appreciate those of you who take the time to remind folks of the pre-ship status of the code. Nevertheless we’re happy that many are seeing good results thus far. We're not yet as happy as we believe we will be when we finish the product as we continue to work on all the fundamental capabilities of Windows 7 as well as all the new features folks are excited about.
Writing about performance in this blog is nearly as tricky as measuring it. As we've seen directional statements are taken further than we might intend and at the same time there are seemingly infinite ways to measure performance and just as many ways to perceive the same data. Ultimately, performance is something each individual feels is right--whether than means adequate or stellar might vary scenario to scenario, individual to individual. Some of the mail we've received has been clear about performance:
You can also see through some of these quotes that performance means something different to different people. As user-interface folks know, perceived performance and actual performance can often be different things. I [Steven] remember when I was writing a portion of the Windows UI for Visual C++ and when I benchmarked against Borland C++ at the time, we were definitely faster (measured by seconds). However the reviews consistently mentioned Borland as being faster and providing feedback in the form of counts of lines compiled flying by. So I coded up a line count display that flashed a lot of numbers at you while compiling (literally flashy so it looked like it couldn't keep up). In clock times it actually consumed a non-zero amount of time so we got "slower" but the reviewers then started giving us credit for being faster. So in this case slower actually got faster.
There's another story from the past that is the flip side of this which is the scrolling speed in Microsoft Word for DOS (and also Excel for Windows--same dynamic). BillG always pushed hard on visible performance in the "early" days and scrolling speed was one of those things that never seemed to be fast enough. Well clever folks worked hard on the problem and subsequently made scrolling too fast--literally to the point that we had to slow it down so you didn't always end up going from page 1 to the end of the document just because you hold down the page down key. It is great to be fast, but sometimes there is "too much speed".
We have seen the feedback about what to turn off or adjust for better performance. In many ways what we're seeing are folks hoping to find the things that cause the performance to be less than they would like. I had an email conversation with someone recently trying to pinpoint the performance issues on a new laptop. Just by talking through it became clear the laptop was pretty "clean" (~40 processes, half the 1GB of RAM free, <5% CPU at idle, etc.) and after a few back and forths it became clear it was the internet connection (dial-up) that was actually the biggest bottleneck in the system. Many encourage us to turn off animations, graphics, or even color as there is a belief that these can be the root of performance. We've talked about the registry, disk space utilization, and even color depth as topics where folks see these as potential performance issues.
It is important to consider that performance is inherently a time/space tradeoff (computer science sense, not science fiction sense), and on laptops there is the added dimension of power consumption (or CPU utilization). Given infinite memory, of course many algorithms would be very different than the ones we use. In finite memory, performance is impacted greatly by the overall working set of a scenario. So in many cases when we talk about performance we are just as much talking about reducing the amount of memory consumed as we are talking about the clock time. Some parts of the OS are much more tunable in terms of the memory they use, which then improves the overall performance of the system (because there is less paging). Other parts of the system are much more about the number of instructions executed (because perhaps every operation goes through that code path). We work a great deal on both!
The reality of measuring and improving performance is one where we are focused at several "levels" in Windows 7: micro-benchmarks, specific scenarios, system tuning. Each of these plays a critical role in how we are engineering Windows 7 and while any single one can be measured it is not the case that one can easily conclude the performance of the system from a measurement.
Micro-benchmarks. Micro-benchmarks are the sort of tests that stress a specific subsystem at extreme levels. Often these are areas of the code that are hard to see the performance of during usage as they go by very fast or account for a small percentage of time during overall execution. So tests are designed to stress part of the system. Many parts of the system are subjected to micro-benchmarking such as the file system, networking, memory management, 2D and 3D graphics, etc. A good example here is the work we do to enable fast file copying. There is a lot of low level code that accounts for a (very significant) number of conditions when copying files around, and that code is most directly executed through XCOPY in a command window (or an API). Of course the majority of copy operations take place through the explorer and along with that comes a progress indicator, cancellable operation, counting up bytes to copy, etc. All of those have some cost with the benefit as well. The goal of micro-benchmarks is to enable us to best understand the best possible case and then compare it to the most usable case. Advanced folks always have access to the command line for more power, control, and flexibility. It is tempting to measure the performance of the system by looking at improvements in micro-benchmarks, but time and time again this proves to be inadequate as routine usage covers a much broader code path and time is spent in many places. For Internet Explorer 8 we did a blog post on performance that went into this type issue relative to script performance. At the other end of the spectrum we definitely understand the performance of micro-benchmarks on some subsystems will be, and should be, carefully measured --the performance of directx graphics is an area that gamers rely on for example. It is worth noting that many micro-benchmarks also depend heavily on a combination of Windows OS, hardware, and specific drivers.
Specific scenarios. Most people experience the performance of a PC through high level actions such as booting, standby/resume, launching common applications. These are topics we have covered in previous posts to some degree. In Engineering Windows 7, each team has focused on a set of specific scenarios that are ones we wanted to make better. This type of the work should be demonstrable without any elaborate setup or additional tools. This work often involves tuning the code path for the number of instructions executed, looking at the data allocated for the common case, or understanding all the OS APIs called (for example registry lookups). One example that comes to mind is the work that we have going on to reduce the time to reinsert a USB device. This is particularly noticeable for UFD (USB flash drives) or memory cards. Windows of course allows the whole subsystem to be plumbed by unique drivers for a specific card reader or UFD, even if most of the time they are the same we still have to account for the variety in the ecosystem. At the start of the project we looked at a full profile of the code executed when inserting a UFD and worked this scenario end-to-end. Then systematically each of the "hot spots" was worked through. Another example along these lines was playback of DVD movies which involves not only the storage subsystem but the graphics subsystem as well. The neat thing about this scenario is that you also want to optimize for the CPU utilization (which you might not even notice while playing back the movie) as that dictates the power consumption.
System tuning. A significant amount of performance work falls under the umbrella of system tuning. To ascertain what work we do in this area we routinely look at the overall performance of the system relative to the same tests on previous builds and previous releases of Windows. We're looking for things that we can do to remove operations that take a lot of time/space/power or things that have "grown" in one of those dimensions. We have build-to-build testing we do to make sure we do not regress and of course every developer is responsible for making sure their area improves as well. We left no stone unturned in terms of investigating opportunities to improve. One of the areas many will notice immediately when looking at the pre-beta or beta of Windows 7 is the memory usage (as measured by task manager, itself a measurement that can be misunderstood) of the desktop window manager. For Windows 7, a substantial amount of architectural work went into reducing the amount of memory consumed by the subsystem. We did this work while also maintaining compatibility with the Windows Vista drivers. We did similar work on the desktop search engine where we reduced not just the memory footprint, but the I/O footprint as well. One the most complex areas to work on was the improvements in the taskbar and start menu. These improvements involved substantial work on critical sections ("blocking" areas of the code), registry I/O, as well as overall code paths. The goal of this work is to make sure these UI elements are always available and feel snappy.
It is worth noting that there are broad based measures of performance as well that drive the user interface of a selection of applications. These too have their place--they are best used to compare different underlying hardware or drivers with the same version of Windows. The reason for this is that automation itself is often version dependent and because automation happens in a less than natural manner, there can be a tendency to measure these variances rather than any actual perceptible performance changes. The classic example is the code path for drawing a menu drop down--adding some instructions that might make the menu more accessible or more appealing would be impossible to perceive by a human, but an automated system that drives the menu at super human speed would see a change in "performance". In this type of situation the effect of a micro-benchmark is magnified in a manner inconsistent with actual usage patterns. This is just a word of caution on how to consider such measurements.
Given this focus across different types of measurement it is important to understand that the overall goal we have for Windows 7 is for you to experience a system that is as good as you expect it to be. The perception of performance is just as important as specific benchmarks and so we have to look to a broad set of tools as above to make sure we are operating with a complete picture of performance.
In addition to these broad strategies there are some specific tools we've put in place. One of these tools, PerfTrack, takes the role of data to the next level with regard to performance and so will play a significant role in the beta. In addition, it is worth reminding folks about the broad set of efforts that go into engineering for performance:
Perftrack is a very flexible, low overhead, dynamically configurable telemetry system. For key scenarios throughout Windows 7, there exist “Start” and “Stop” events that bracket the scenario. Scenarios can be pretty much anything; including common things like opening a file, browsing to a web page, opening the control panel, searching for a document, or booting the computer. Again, there are over 500 instrumented scenarios in Windows 7 for Beta.
Obviously, the time between the Stop and Start events is meant to represent the responsiveness of the scenario and clearly we’re using our telemetry infrastructure to send these metrics back to us for analysis. Perftrack’s uniqueness comes not just from what it measure but from the ability to go beyond just observing the occurrence of problematic response times. Perftrack allows us to “dial up” requests for more information, in the form of traces.
Let’s consider the distribution below and, for fun, let's pretend the scenario is opening XYZ. For this scenario, the feature team chose to set some goals for responsiveness. With their chosen goals, green depicts times they considered acceptable, yellow represents times they deemed marginal, and red denotes the poor times. The times are in milliseconds and shown along the X axis. The Hit Count is shown on the Y axis.
As can be seen, there are many instances where this scenario took more than 5 seconds to complete. With this kind of a distribution, the performance team would recommend that we “dial up” a request for 100+ traces from systems that have experienced a lengthy open in the past. In our “dialed up” request, we would set a “threshold” time that we thought was interesting. Additionally, we we may opt to filter on machines with a certain amount of RAM, a certain class of processor, the presence of specific driver, or any number of other things. Clients meeting the criteria would then, upon hitting the “Start” event, configure and enable tracing quickly and potentially send back to us if the “Stop” event occurred after our specified “threshold” of time.
As you might imagine, a good deal of engineering work went into making this end to end telemetry and feedback system work. Teams all across the Windows division have contributed to make this system a reality and I can assure you we’ll never approach performance the same now that we have these capabilities.
As a result of focusing on traces and fixing the very real issue revealed by them, we’ve seen significant improvements in actual responsiveness and have received numerous accolades on Windows 7. Additionally, I’d like to point out that these traces have served to further confirm what we’ve long believed t be the case.
This post provides an overview of the ways we have thought about performance with some specifics about how we measure it throughout the engineering of Windows 7. We believe that throughout the beta we will continue to have great telemetry to help make sure we are achieving our goals and that people perceive Windows 7 to perform well relative to their expectations.
We know many folks will continue to use stop watches, micro-benchmarks, or to drive automated tests. These each have their place in your own analysis and also in our engineering. We thought given all the interest we would talk more about how we measure things and how we're engineering the product.
--Steven and Michael