Sort By:

Idle-Time Garbage-Collection Scheduling

Taking advantage of idleness to reduce dropped frames and memory consumption

by Ulan Degenbaev, Jochen Eisinger, Manfred Ernst, Ross McIlroy, Hannes Payer | July 26, 2016

CACM This article appears in print in Communications of the ACM, Volume 59 Issue 10


Hadoop Superlinear Scalability

The perpetual motion of parallel performance

by Neil Gunther, Paul Puglia, Kristofer Tomasette | June 4, 2015


The API Performance Contract

How can the expected interactions between caller and implementation be guaranteed?

by Robert Sproull, Jim Waldo | January 30, 2014


How Fast is Your Web Site?

Web site performance data has never been more readily available.

by Patrick Meenan | March 4, 2013

CACM This article appears in print in Communications of the ACM, Volume 56 Issue 4


Thinking Methodically about Performance

The USE method addresses shortcomings in other commonly used methodologies.

by Brendan Gregg | December 11, 2012

CACM This article appears in print in Communications of the ACM, Volume 56 Issue 2


Extending the Semantics of Scheduling Priorities

Increasing parallelism demands new paradigms.

by Rafael Vanoni Polanczyk | June 14, 2012

CACM This article appears in print in Communications of the ACM, Volume 55 Issue 8


Thinking Clearly about Performance

Improving the performance of complex software is difficult, but understanding some fundamental principles can make it easier.

by Cary Millsap | September 1, 2010


You're Doing It Wrong

Think you've mastered the art of server performance? Think again.

by Poul-Henning Kamp | June 11, 2010

CACM This article appears in print in Communications of the ACM, Volume 53 Issue 7


Modern Performance Monitoring

The modern Unix server floor can be a diverse universe of hardware from several vendors and software from several sources. Often, the personnel needed to resolve server floor performance issues are not available or, for security reasons, not allowed to be present at the very moment of occurrence. Even when, as luck might have it, the right personnel are actually present to witness a performance “event,” the tools to measure and analyze the performance of the hardware and software have traditionally been sparse and vendor-specific.

by Mark Purdy | February 23, 2006


Performance Anti-Patterns

Performance pathologies can be found in almost any software, from user to kernel, applications, drivers, etc. At Sun we’ve spent the last several years applying state-of-the-art tools to a Unix kernel, system libraries, and user applications, and have found that many apparently disparate performance problems in fact have the same underlying causes. Since software patterns are considered abstractions of positive experience, we can talk about the various approaches that led to these performance problems as anti-patterns—something to be avoided rather than emulated.

by Bart Smaalders | February 23, 2006


A High-Performance Team

You work in the product development group of a software company, where the product is often compared with the competition on performance grounds. Performance is an important part of your business; but so is adding new functionality, fixing bugs, and working on new projects. So how do you lead your team to develop high-performance software, as well as doing everything else? And how do you keep that performance high throughout cycles of maintenance and enhancement?

by Philip Beevers | February 23, 2006


Hidden in Plain Sight

In December 1997, Sun Microsystems had just announced its new flagship machine: a 64-processor symmetric multiprocessor supporting up to 64 gigabytes of memory and thousands of I/O devices. As with any new machine launch, Sun was working feverishly on benchmarks to prove the machine’s performance. While the benchmarks were generally impressive, there was one in particular—an especially complicated benchmark involving several machines—that was exhibiting unexpectedly low performance. The benchmark machine—a fully racked-out behemoth with the maximum configuration of 64 processors—would occasionally become mysteriously distracted: Benchmark activity would practically cease, but the operating system kernel remained furiously busy.

by Bryan Cantrill | February 23, 2006