CST 334 - Operating Systems (Week 7)

 This week, I want to move away from the studying material to my group project, which is also... reading document. However, my team and I found this article interesting and beneficial. The paper's title is "Relational Debugging —Pinpointing Root Causes of Performance Problems" by many authors in university of Toronto and university of Illinois.

Right from the title, we can see how this document can be interesting. For many of us, we are the users, and performance / stability is a crucial key aspect. Even though there are many tools and algorithms that help improve performance for applications, programmers cannot simply ignore and make a hasty program. However, performance problems are not easily handled. Coding the algorithm having a good performance is hard enough, finding and fixing the problem are another story. In that article, I learned that performance problems are very sneaky. They seem acting normal, doesn't crash your program, which make detecting the problem harder. It might be too late when the application slow down gradually, or performance downgrade significantly, and the program is crashed without a single warning. Now, if you don't think that is bad enough, imagine you have to look through not hundreds, but at least few thousand lines of code to find where the problem is.

So, the authors introduce in the document a tool named Perspect. This tool is not just going to help with detecting the performance problem, but it can locate where the problem is in lines of code. What I found fascinating was how the authors come up with the algorithm, similar concept with speed in physics. With the same program (same distance), but two runs give two different times, that mean the speed on those runs are not the same. So, Perspect make the program runs twice, and if there is any performance problem that slows down the program, it will detect through the time. However, I did not dive in too deep on how the authors pinpoint the location of the problem. I don't want my brain to get overload and start switching to virtual memory for additional space (and reduce performance).

There are many other amazing aspects that I think the authors have done a good job with, such as: the upcoming plan for the tool; how the experiment was set up; the not-so-flawless with 10/12 passed test cases. However, I could not talk about them all here but give it a try if you find it interest like my team and I did.

Relational Debugging --- Pinpointing Root Causes of Performance Problems