De juiste tijd om de prestaties van het Uitzicht van Vensters te beoordelen
Het meten van de prestaties van een werkend systeem is een netelig ding. Tezelfdertijd het het juiste en noodzakelijke te doen ding is, omdat de prestaties één van vele criteria belangrijk voor klanten zijn. Een deel van de truc van het meten van prestaties is aan tijd testende uitvoering met de productcyclus dusdanig dat de resultaten voor klanten zo zinvol mogelijk zijn; dit helpt hen een beter besluit nemen door de van volledige serie van beschikbare informatie gebruik te maken. Als één voorbeeld, over een jaar geleden droegen wij een firma op die Principiele Technologieën wordt genoemd aan voer een studie uit het vergelijken van SP2 van Vensters XP bij het Uitzicht RTM van Vensters. Die studie vond de prestatiesmaatregelen van de twee werkende systemen binnen de zelfde waaier voor vele taken waren die het huis en de zakelijke gebruikers vaak in real-world omstandigheden uitvoeren.
Mijn punt is dat wij wachtten om deze evaluerende tests uit te voeren tot het Uitzicht van Vensters de mijlpaal RTM in de productcyclus had bereikt, zoals dit toestonden ons om onze klanten te verstrekken de meest zinvole tegelijkertijd beschikbare gegevens -- de gegevens het waarschijnlijkst hun besluit direct om te beïnvloeden om aan Vensters Uitzicht te bevorderen. Wij doen een gehele waaier van prestatiestests in elk stadium van het OS ontwikkelingsproces, maar als algemene regel, vermijden wij delend benchmarktests van software die niet RTM (d.w.z., definitieve code) is gegaan. Dit verklaart waarom wij tot op heden geen bevindingen van benchmarktests (hebben gepubliceerd noch iedereen om dit opgedragen te doen) aangaande de prestatiesverbeteringen die door SP1 van het Uitzicht van Vensters worden bewerkstelligd. Het publiceren benchmarks van de prestaties van SP1 van het Uitzicht van Vensters nu zouden geen lonende oefening voor onze klanten, aangezien de code nog in ontwikkeling en is, aan de graad dat de evaluerende tests geïmpliceerda zijn, een moving target blijft zijn.
Ongeacht dat punt, laat me ook benadrukken dat er een verscheidenheid van manieren zijn om de prestaties van een PC te evalueren. De verschillende technieken kunnen verschillende resultaten opleveren. Sommige benchmarktechnieken testen eenvoudig de hardwareprestaties van PC door een reeks taken bij bovenmenselijke snelheid in werking te stellen. Dergelijke tests neigen om kleine verschillen tussen testplatforms te overdrijven en tegenwoordig minder vaak bijgevolg gebruikt, vervangen ten gunste van benchmarks die taken in werking stellen bij menselijke snelheden met realistisch wacht en invoer van gegevens. De benchmarks die vaak bij bovenmenselijke snelheden lopen leveren resultaten die niet het gehele verhaal vertellen. In feite, maakten wij weloverwogen keuzen tijdens de ontwikkeling van het Uitzicht van Vensters om ons op real-world scenario's te concentreren die gebruikerservaring, eerder dan zich het concentreren op verbetering van microsecondeverrichtingen onwaarneembaar beïnvloeden aan de gebruiker. In addition, in Windows many operations can require additional processing time for work that is done for reasons that benefit the customer; these can include security, reliability or application compatibility checks conducted when a program launches. These operations may add microseconds to an individual application's launch that under real usage isn't perceivable to the human eye. When thousands such operations are strung together through automation, those few microseconds can have a cumulative effect on the benchmark result, causing performance to appear much better or worse than expected.
I've included below a video we captured depicting a "benchmark test" running a window-open, window-close routine at accelerated speed. You can see that it isn't representative of real-world user behavior and hence isn't an accurate gauge of the actual end-user experience. Further, tests like these only measure a very small set of Windows capabilities and so aren't representative of the user's overall day-to-day experience of working with Windows and running applications.
Video: Windows Vista benchmark testing
Methods like those of Principled Technologies that actually approximate the experience of using the PC, taking an OS through the paces of completing actual tasks at the approximate pace a user might click through them, tend to provide results far more useful to our customers. The typical Windows customer generally wants to know how his/her actual computing experience will change (read: improve) with an upgrade. The Principled Technologies tests do that.
For what it's worth, I can personally attest that I prefer to get my work done on Windows Vista SP1 RC bits. I run Windows Vista RTM on two production machines and SP1 RC bits on two others; in fact, I'm writing this post on a machine with SP1 RC bits installed. As a part of our internal SP1 testing program, I know that we continue to develop and improve SP1 every day, in large part based on feedback and bug submissions from external an internal Beta-test program members. IMO, the perceived gains in performance between SP1 Beta and SP1 RC code are significant. As I said at the beginning, though, performance is only part of the story -- don't forget that SP1 also brings support for new types of hardware and several emerging standards, and further eases an IT administrator's deployment and management efforts.
But don't take my word alone for it. We'll broaden the testing pool of SP1 RC bits soon (very soon), so when I post that notice here on the blog, you'll be able to put Windows Vista SP1 RC through its paces yourself. I think you'll find the experience worthwhile and satisfying.
Written by Nick White. Read more great feeds at is source WEBSITE
no comments.
Read more articles on Performance and otherSoftware and Service Pack 1 and SP1 and Featured News and Windows Vista.
- [+] Digg: Feature this article
- [+] Del.icio.us: Bookmark this article
- [+] Furl: Bookmark this article
