Performance

Vol. 10 No. 12 – December 2012

Performance

Code Abuse

One programmer's extension is another programmer's abuse.

During some recent downtime at work, I've been cleaning up a set of libraries, removing dead code, updating documentation blocks, and fixing minor bugs that have been annoying but not critical. This bit of code spelunking has revealed how some of the libraries have been not only used, but also abused. The fact that everyone and their sister use the timing library for just about any event they can think of isn't so bad, as it is a library that's meant to call out to code periodically (although some of the events seem as if they don't need to be events at all). It was when I realized that some programmers were using our socket classes to store strings -- just because the classes happen to have a bit of variable storage attached, and some of them are globally visible throughout the system -- that I nearly lost my lunch. We do have string classes that could easily be used, but instead these programmers just abused whatever was at hand. Why?

by George Neville-Neil

Articles

Thinking Methodically about Performance

The USE method addresses shortcomings in other commonly used methodologies.

Performance issues can be complex and mysterious, providing little or no clue to their origin. In the absence of a starting point or a methodology to provide one, performance issues are often analyzed randomly: guessing where the problem may be and then changing things until it goes away. While this can deliver results -- if you guess correctly -- it can also be time-consuming, disruptive, and may ultimately overlook certain issues. This article describes system-performance issues and the methodologies in use today for analyzing them, and it proposes a new methodology for approaching and solving a class of issues.

by Brendan Gregg

Rethinking Passwords

Our authentication system is lacking. Is improvement possible?

There is an authentication plague upon the land. We have to claim and assert our identity repeatedly to a host of authentication trolls, each jealously guarding an Internet service of some sort. Each troll has specific rules for passwords, and the rules vary widely and incomprehensibly. Password length requirements vary: Dartmouth wants exactly eight characters; my broker, six to eight; Wells Fargo, eight or more. Special characters are often encouraged or required, but some characters are too special: many disallow spaces, single or double quotes, underlines, or hyphens. Some systems disallow certain characters at the beginning of the password; dictionary checks abound, including foreign language dictionaries.

by William Cheswick