Software slug

A Software slug (or just "slug", short for "slowness bug") is a Software bug that only makes a program slow, but not incorrect. Programs as first written generally contain both bugs and slugs. Bugs are usually removed during program testing, while slugs are usually not, unless performance analysis is employed during development. Slugs can sometimes increase execution time by one or more orders of magnitude.

There are different kinds of slugs. Generally, things that could be done intentionally to make a program run longer can also occur unintentionally. One commonly accepted kind of slug is a hot spot, which is a tight inner loop where the program counter spends much of its time. For example, if one often finds at the bottom of the call stack a linear search algorithm instead of binary search, this would be a true hot spot slug. However, if another function is called in the search loop, such as string compare, then the string compare function would be found at the bottom of the stack, and the call to it in the loop would be at the next level up. In this case, the loop would still be a slug, but it would not be a hot spot. In all but the smallest programs, hot spot slugs are rare, but slugs are quite common.

Data structures that are too general for the problem at hand might also impair performance. For example, if a collection of objects remains small, a simple array with linear search could be much faster than something like a "dictionary" class, complete with hash coding. With this kind of slug, the program counter is most often found in "housekeeping" such as dynamic memory allocation/de-allocation as these collections are being constructed and then 'destructed'.

Another common motif is that a powerful function is written to collect a set of useful information (from a database, for example). Then that function is called multiple times, rather than taking the trouble to save the results from a prior call. A possible explanation for this could be that it is beyond a programmer's comprehension that a function call might take a million times as long to execute as an adjacent assignment statement. A contributing factor could be information hiding, in which external users of a module can be ignorant of what goes on inside it.

References

• Dunlavey, “Performance tuning with instruction-level cost derived from call-stack sampling”, ACM SIGPLAN Notices 42, 8 (August, 2007), pp. 4-8.
• Dunlavey, “Performance Tuning: Slugging It Out!”, Dr. Dobb's Journal, Vol 18, #12, November 1993, pp 18-26.