BenchmarkXPRT Blog banner

Category: Performance benchmarking

Digging deeper

From time to time, we like to revisit the fundamentals of the XPRT approach to benchmark development. Today, we’re discussing the need for testers and benchmark developers to consider the multiple factors that influence benchmark results. For every device we test, all of its hardware and software components have the potential to affect performance, and changing the configuration of those components can significantly change results.

For example, we frequently see significant performance differences between different browsers on the same system. In our recent recap of the XPRT Weekly Tech Spotlight’s first year, we highlighted an example of how testing the same device with the same benchmark can produce different results, depending on the software stack under test. In that instance, the Alienware Steam Machine entry included a WebXPRT 2015 score for each of the two browsers that consumers were likely to use. The first score (356) represented the SteamOS browser app in the SteamOS environment, and the second (441) represented the Iceweasel browser (a Firefox variant) in the Linux-based desktop environment. Including only the first score would have given readers an incomplete picture of the Steam Machine’s web-browsing capabilities, so we thought it was important to include both.

We also see performance differences between different versions of the same browser, a fact especially relevant to those who use frequently updated browsers, such as Chrome. Even benchmarks that measure the same general area of performance, for example, web browsing, are usually testing very different things.

OS updates can also have an impact on performance. Consumers might base a purchase on performance or battery life scores and end up with a device that behaves much differently when updated to a new version of Android or iOS, for example.

Other important factors in the software stack include pre-installed software, commonly referred to as bloatware, and the proliferation of apps that sap performance and battery life.

This is a much larger topic than we can cover in the blog. Let the examples we’ve mentioned remind you to think critically about, and dig deeper into, benchmark results. If we see published XPRT scores that differ significantly from our own results, our first question is always “What’s different between the two devices?” Most of the time, the answer becomes clear as we compare hardware and software from top to bottom.

Justin

Experience is the best teacher

One of the core principles that guides the design of the XPRT tools is they should reflect the way real-world users use their devices. The XPRTs try to use applications and workloads that reflect what users do and the way that real applications function. How did we learn how important this is? The hard way—by making mistakes! Here’s one example.

In the 1990s, I was Director of Testing for the Ziff-Davis Benchmark Operation (ZDBOp). The benchmarks ZDBOp created for its technical magazines became the industry standards, because of both their quality and Ziff-Davis’ leadership in the technical trade press.

WebBench, one of the benchmarks ZDBOp developed, measured the performance of early web servers. We worked hard to create a tool that used physical clients and tested web server performance over an actual network. However, we didn’t pay enough attention to how clients actually interacted with the servers. In the first version of WebBench, the clients opened connections to the server, did a small amount of work, closed the connections, and then opened new ones.

When we met with vendors after the release of WebBench, they begged us to change the model. At that time, browsers opened relatively long-lived connections and did lots of work before closing them. Our model was almost the opposite of that. It put vendors in the position of having to choose between coding to give their users good performance and coding to get good WebBench results.

Of course, we were horrified by this, and worked hard to make the next version of the benchmark reflect more closely the way real browsers interacted with web servers. Subsequent versions of WebBench were much better received.

This is one of the roots from which the XPRT philosophy grew. We have tried to learn and grow from the mistakes we’ve made. We’d love to hear about any of your experiences with performance tools so we can all learn together.

Eric

A new HDXPRT 2014 build is available

Last fall, we identified a way to run HDXPRT 2014, originally developed for Windows 8, on Windows 10. The method involved overwriting the HDXPRT CPU-Z files with newer versions and performing a few additional pre-test configuration steps. You can read more details about those steps here.

Today, we’re releasing a new build of HDXPRT 2014 (v1.2) that eliminates the need to overwrite the CPU-Z files. The new build is available for download at HDXPRT.com. Please note that the app package is 5.08 GB, so allow time and space for the download process.

We also updated the HDXPRT 2014 User Manual to reflect changes in pre-test system configuration and to include the settings we recommend for newer builds of Windows 10.

The changes in the new build do not affect results, so v1.2 scores are comparable to v1.1 scores on the same system.

The new build ran well during testing in our labs, but issues could emerge as Microsoft releases new Windows updates. If you have any questions about HDXPRT or encounter any issues during testing, we encourage you to let us know.

We look forward to seeing your test results!

Justin

BatteryXPRT 2014 gets an update

After Android 7 (Nougat) was released on select devices this past fall, we discovered an issue with BatteryXPRT on devices running Android 7 and above. The battery life tests were completing accurately and reliably, but the test was not producing a performance score.

The problem was a result of significant changes in the Android development environment. Android 7 restricted the flags used for different target architectures when linking native code components, and that caused issues while executing part of the Create Slideshow workload. We resolved the issue by changing the linked flags. Also, we migrated the BatteryXPRT code from the Eclipse and Android SDK development environments to the up-to-date Android Studio environment. This allowed us to rebuild the app in a way that maintains compatibility with the most recent versions of Android.

Today, we’re releasing a new build of BatteryXPRT 2014 (v104) at BatteryXPRT.com and the Google Play store. Scores from this build are comparable with previous BatteryXPRT scores, and if you’re testing with a version of BatteryXPRT that you downloaded from the Google Play store, you should receive the new build via an app update.

Click here to download the new BatteryXPRT installer (330 MB) directly from our site.

For users who have limited bandwidth or trouble accessing the Google Play store, downloading the APK files (26.7 MB total) may make installation easier.

Download the updated BatteryXPRT APK (2.8 MB) directly from our site.

Download the updated BatteryXPRT Tests APK (23.9 MB) directly from our site.

If you have any questions about the update or any other XPRT-related topic, feel free to contact us at BenchmarkXPRTSupport@principledtechnologies.com.

Justin

CrXPRT’s future

This week, we’re continuing our review of the XPRT portfolio by discussing the future of CrXPRT. CrXPRT, designed for use with Chrome OS, is a tool for evaluating the performance and battery life of Chromebooks as they handle everyday tasks. The app’s performance test, which measures Chromebook speed, produces an overall score and individual scores for each workload. The battery life test produces an estimated battery life and a separate performance score. CrXPRT is easy to install and use, and like BatteryXPRT, it evaluates battery life in half a workday.

We developed CrXPRT in response to the growing popularity of Chromebooks, especially in the education sector. The number of OEMs manufacturing Chromebooks has grown dramatically, along with the range of Chromebook price points and form factors. That growth shows no signs of slowing down, so CrXPRT is more relevant than ever as a tool for helping consumers make informed buying decisions.

As Chromebook market share continues to grow, however, it’s clear that significant changes to the Chrome OS environment are on the way. One big change is Google’s decision to bring Android apps, and the Google Play store itself, to Chrome OS. Another change is the plan to “begin the evolution away” from the Chrome apps platform and phase out Chrome app support on other platforms within the next two years.

There are also reports of a hybrid Android-Chrome OS operating system. Codenamed “Andromeda,” it would unite the Android and Chrome OS environments in a manner similar to the way Microsoft Continuum allows Windows 10 to run on a wide variety of device types. Details on Andromeda are few and far between, but it would obviously be a game changer.

The Google Play store rollout to select Chromebooks is already well underway. As for the other changes, it remains to be seen exactly when and how they will be implemented. The Chromium team did state that all types of Chrome apps will remain supported and maintained on Chrome OS for the foreseeable future.

For us, it’s important to maintain the ability to measure both performance and battery life on Chromebooks. The current version of CrXPRT does the job well, so we don’t see a need for a new version until the situation becomes more clear. In the meantime, we’ll be keeping an eye on Chrome-related news.

As always, we’re interested in your feedback. If you have any thoughts on CrXPRT 2015 or the future of Chromebook evaluation, let us know!

Justin

WebXPRT in 2017

Over the last few weeks, we’ve discussed the future of HDXPRT and BatteryXPRT. This week, we’re discussing what’s in store for WebXPRT in 2017.

WebXPRT is our most popular tool. Manufacturers, developers, consumers, and media outlets in more than 350 cities and 57 countries have run WebXPRT over 113,000 times to date. The benchmark runs quickly and simply in most browsers and produces easy-to-understand results that are useful for comparing web browsing performance across a wide variety of devices and browsers. People love the fact that WebXPRT runs on almost any platform that has a web browser, from PCs to phones to game consoles.

More people are using WebXPRT in more places and in more ways than ever before. It’s an unquestioned success, but we think this is a good time to make it even better by beginning work on WebXPRT 2017. Any time change comes to a popular product, there’s a risk that faithful fans will lose the features and functionality they’ve grown to love. Relevant workloads, ease of use, and extensive compatibility have always been the core components of WebXPRT’s success, so we want to reassure users that we’re committed to maintaining all of those in future versions.

Some steps in the WebXPRT 2017 process are straightforward, such as the need to reassess the existing workload lineup and update content to reflect advances in commonly used technologies. Other steps, such as introducing new workloads to test emerging browser technologies, may be tricky to implement, but could offer tremendous value in the months and years ahead.

Are there test scenarios or browser technologies you would like to see in WebXPRT 2017, or tests you think we should get rid of? Please let us know. We want to hear from you and make sure that we’re crafting a performance tool that continues to meet your needs.

Bill

Check out the other XPRTs:

Forgot your password?