Case Study Info

Phone Number Recognizer Refactoring

.pdfSkype Phone number recognizer refactioring.pdf

The Challenge

Skype is one of the best known companies on the planet, and there is no one even close to rivaling them in the field of Voice over Internet Protocol communications. So closely are they associated with this technology that the very word ‘Skype’ has become a part of many of the world’s languages in much the same way as ‘Google’. Like any company, reputation is everything and for an IT company like Skype reputation is inextricably linked with reliability, and not just of the main platform. Customers can quickly become exasperated with particular tools or applications that do not perform well, and this can have a serious and lasting impact on the success of the whole project and potentially of the company. Skype has identified a critical weakness on their products and needed the problem sorted out quickly and effectively.

They turn to Softage for help.

Skype knows that one particular piece of their system, the Phone Number Recogniser  (PNR) is not performing well. Their customers are becoming frustrated with it, and that frustration is beginning to spill over into dissatisfaction with the whole Skype brand. The problem seems to be that there are bottlenecks and errors in the PNR code, and that these are causing the tool to perform poorly or even to hang altogether. Skype asks Softage to have a close look at the code and turn in a detailed report on any flaws found. Our team of developers is able to study the code in minute detail and identify many faults and flaws which need attention. Skype is so pleased with the thoroughness of the report they ask our people to stay on and work to cure the problems they have identified. Our software consultants are able to deliver on all the requirements Skype lays down within the constraints specified.

Solution Overview

Our team quickly identifies the problem, devises and implements solutions, rolling out a much improved PNR. The Skype team is delighted with the results. The revised PNR is twelve times as effective as the previous version. It finds more telephone numbers  faster and more reliably. On top of this, Softage manages to greatly reduce the size of the code in the process.  Not only that, but Softage also configured the tool to become cross platform and it will now work equally well on Windows, Mac OS X or Linux. Phone Number Recognizer Refactoring is the name of this project.

Main Features

Our team is presented three principal tasks by the Skype engineers. First of all, they want us to reconfigure the code to improve the stability and performance of the tool. Secondly, they want the PNR to not only recognize more phone numbers, but also to be better at analyzing the numbers it finds and attributing the right characteristics to them. For example, whether the number is a mobile or landline, whether it is a fax number, and whether or not it has the right country code attributed to it. Finally, they want the PNR to be code ported to the Mac for OS X and to Linux. All this is to be achieved without any significant increase in the amount of code and with a finished product which will find at least as many phone numbers as the previous unstable version would have found.

Softage’s team of developers and programmers adopts a variety of approaches to improving system performance. They identify early on that a key weakness of the old PNR is that it makes excessive use of data copying rather than referring back to the original reference. This is inefficient and slow, and requires a great deal more code to accomplish. So we remove the majority of copy constructors and assignment operators, and make the remaining ones private in order to avoid any unexpected copy operations.

In a similar vein, we found that the results of calculations are not being stored, even when the value is going to be needed again, and this necessitates the same calculation being carried out many times. This is particularly common with loop border conditions and constant array sizes. Where it is possible, our team revises the code to store the results of a calculation as a temporary variable or private class member and then to refer back to that value rather than repeating the calculation. They also seek to optimize the algorithms to ensure, where possible, that binary rather than linear searches are carried out, thus greatly reducing the time that a complete search takes.

Stability is a particular issue with the previous version of PNR and remains a key area for attention. Our Softage team identifies a number of issues contributing to it. To begin with, exception handling is very poor. Internal exceptions are being thrown, leaving the PNR code which causes the tool to crash. They are able to enclose all the external functional interfaces between PNR and outside code with try-catch blocks which produce a dramatic improvement in stability. This improvement is further enhanced by the introduction of thread synchronizations to prevent objects changing in several threads at the same time.

The second area of difficulty our team identifies is with dynamic memory usage. This is very poorly controlled in the original PNR and is causing very significant memory leaks. Where possible, our team removes dynamic memory usage altogether, and where this isn’t possible, they introduced greatly improved controls for it.

A further weakness is identified with object lifetime control, where there’s a requirement to use an object in many places, making assigning a single owner impossible. Reference counters are introduced to control object lifetime.

Although there are a host of other minor issues and problems that we address, there is one final significant flaw which, when rectified, gives a huge improvement in reliability: We see routines being executed in one part of the PNR crossing over into other parts of the tool, causing the tool to slow down or to hang. Softage introduces a black box (super secret, we’re not going to tell you) concept to the coding which prevents a routine in one part of the tool from being able to see operations elsewhere, thus forcing them to remain within the boundaries of their own operation.

Tools and technologies

Our developers draw on their acknowledged expertise to deliver a significantly improved PNR for Skype. They employ Microsoft Visual Studio 2005, the Xcode 3 series, the Boost C++ Library and Active Template Library to deliver a solution on time and on budget!