A PhD student working with the Platform Research group at SAP has won the Young Investigator Award at this year’s CompArch conference in Vancouver, Canada. Alexander Wert began identifying performance problems using software during his undergraduate dissertation. He posed the question: While programming, is it possible to forecast the impact code will have on the performance of the system as a whole?
In the meantime, Wert’s dissertation, which formed part of his studies in computer science at the Karlsruhe Institute of Technology (KIT), has turned into a postgraduate thesis. And after a year of cooperation with the Platform Research group at SAP, Wert has been able to demonstrate some initial successes.
Testing code during programming
“Using a test system, we managed to see – while programming was going on – whether the existing network or the connection pool were too small,” Wert explains. In other words, he could see if there were enough connections to the database. Wert subjected the test system to an artificial stress test, which enabled him to figure out whether it could stand the load or not.
“It’s a very ambitious undertaking,” says Wolfgang Theilmann, head of the research group at SAP, of Wert’s project. Wert is one of four PhD students in Theilmann’s 12-person research group in Karlsruhe, which focuses on software performance. Their goal is to make research relevant to industry – to put into practice the scientific work that KIT, for example, does.
The method that Wert has chosen for the analysis of potential performance blockers is pattern recognition. Language and computational face recognition use the same principle. They work by recognizing recurring elements in thousands of snippets of language or images of faces, and then by detecting the similarities between them.
Identifying performance issues
When transferred to the programming of software, the first thing that has to be done is to identify the lines of code that could trigger performance issues. “But we can’t check the software manually in a thousand nooks and crannies,” Theilmann explains. Pattern recognition should help here, in the form of this pioneering project.
Next page: A paradigm shift for programming
And it is a paradigm shift, too. At the moment, developers are not interested in the performance of their software. “They write the code until the software works,” Wert says. Only later, once the software has been in use at the company for some while, does a list of issues land on their desks.
“The developers get their knuckles rapped, even though they aren’t performance experts at all,” Wert says. Performance is usually the job of the “operators,” who implement the software in practice. If this correction phase is successfully completed before the software goes live at the customer, it is seen as a giant step. “It saves time and helps to identify problems that haven’t even arisen yet,” says Theilmann.
Correcting issues before software goes live
In the next step, the SuccessFactors HR management software will be examined for any weak spots. This represents the first real stress test in practice.