BenchmarkXPRT Blog banner

Category: Performance benchmarking

WebXPRT 2015 is here!

Today, we’re releasing WebXPRT 2015, our benchmark for evaluating the performance of Web-enabled devices. The BenchmarkXPRT Development Community has been using a community preview for several weeks, but now that we’ve released the benchmark, anyone can run WebXPRT and publish results.

Run WebXPRT 2015

WebXPRT 2013 is still available here while people transition to WebXPRT 2015. We will provide plenty of notice before discontinuing WebXPRT 2013.

After trying out WebXPRT, please send your comments to BenchmarkXPRTsupport@principledtechnologies.com.

More power, more control

As I said last week, the community preview for WebXPRT 2015 is coming up soon. One of the changes that will be exciting to anyone who does a lot of testing is that we made it simpler to automate WebXPRT tests.

WebXPRT 2015 will let you automatically select any set of tests you want to run. However, as always, you must run the entire suite of tests to get an overall score. Although the community preview will not include any experimental tests, the automation includes control for those future tests as well.

You may choose from several output formats: HTML table, XML, and CSV, or you can download the results as a text file.

Using the automation is simple: you just append the desired test parameters to the end of the URL. The format allows you to mix and match a lot of options, while still being very concise. The details will be in the release notes.

As people who test a lot of devices, we are very excited about this new capability.

Eric

An updated MobileXPRT 2013 build is available

Today we’re releasing a new build of MobileXPRT 2013 (b93) at MobileXPRT.com and the Google Play store. The build fixes a problem reported by a reviewer testing the LG G3. The device was going to sleep during the performance test, and causing MobileXPRT to crash after waking up. We’ve seen this problem only on the LG G3, but it may occur on other devices as well.

The new MobileXPRT build keeps the screen active during the run. Scores from this build are comparable with previous MobileXPRT scores.

Click here to download the new MobileXPRT installer (250 MB) directly from our site.

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

Download the updated MobileXPRT APK (10.3 MB) directly from our site.

Download the updated MobileXPRT UX Tests APK (7.6 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.

Upcoming experiments

Next week, we’ll be releasing the design overview for WebXPRT 2015. WebXPRT 2013 has been an enormous success, having been run tens of thousands of times.

One of the big improvements we are considering for WebXPRT 2015 is adding experimental tests. A big reason for WebXPRT’s success is that it runs on almost every Web-enabled device. We consider it essential to preserve this broad compatibility. However, there are interesting Web technologies that simply are not available on all devices.

Our proposal is to add experimental tests to WebXPRT. These tests would be optional and would not be included in the Overall score, so WebXPRT would still be able to compare the performance of widely different devices. We are looking at technologies such as Web Workers, WebGL, and pre-compiled JavaScript (asm.js).

In addition to adding experimental tests, we are looking at ways to improve the UI, add automation, add new tests, update old tests, and more!

If you are a community member, you’ll get a notice when the overview is available. We will definitely want to know what you think! If you are not a member, it’s a great time to join.

If you have any thoughts on these ideas, or have ideas of your own, please let us know!

Eric

Comment on this post in the forums

CrXPRT is here!

Today we are releasing the CrXPRT 2014 Community Preview (CP1). As mentioned in a previous post, CrXPRT contains performance and battery life tests. The performance suite includes five scenarios utilizing Web browsing and JavaScript workloads, plus Portable Native Client (PNaCl) and WebGL-based scenarios. The battery life test incorporates all of the performance workloads and adds video playback, audio playback, and HTML5 gaming scenarios.

The battery life test in CP1 builds on the lessons we learned from developing BatteryXPRT 2014 for Android. In fact, we’ve been able to improve on the testing time. BatteryXPRT 2014 requires 5.5 hours to estimate battery life; CP1 can estimate battery life in only 3.5 hours. The battery test in CP1 still requires the device be put in developer mode, so we’re investigating the new Chrome OS battery status APIs. We hope these will make it possible to remove this restriction in a future release.

The estimates for battery life are generally pretty accurate. However, we have seen runs where the battery life results were much higher than expected. We are continuing to investigate this. If you see an anomalous result, please let us know. It is worth noting that the performance scores have been very consistent.

Because this is a community preview, you have to be a community member to download it. However, joining is very easy.

Check out the new CrXPRT, and let us know what you think!

Eric

Comment on this post in the forums 

Seeing the whole picture

In past posts, we’ve discussed how people tend to focus on hardware differences when comparing performance or battery life scores between systems, but software factors such as OS version, choice of browser, and background activity often influence benchmark results on multiple levels.

For example, AnandTech recently published an article explaining how a decision by Google Chrome developers to increase Web page rendering times may have introduced a tradeoff between performance and battery life. To increase performance, Chrome asks Windows to use 1ms interrupt timings instead of the default 15.6ms timing. Unlike other applications that wait for the default timing, Chrome ends up getting its work done more often.

The tradeoff for that increased performance is that waking up the OS more frequently can diminish the effectiveness of a system’s innate power-saving attributes, such as a tick-less kernel and timer coalescing in Windows 8, or efficiency innovations in a new chip architecture. In this case, because of the OS-level interactions between Chrome and Windows, a faster browser could end up having a greater impact on battery life than might initially be suspected.

The article discusses the limitations of their test in detail, specifically with regards to Chrome 36 not being able to natively support the same HiDPI resolution as the other browsers, but the point we’re drawing out here is that accurate testing involves taking all relevant factors into consideration. People are used to the idea that changing browsers may impact Web performance, but not so much is said about a browser’s impact on battery life.

Justin

Comment on this post in the forums

Check out the other XPRTs:

Forgot your password?