challenge is the move by some developers away from a
tool-based approach to an all-in-one approach.
A tool-based approach can best be understood by
looking at the programs available on any Unix-like system. The use of several programs, mixed and matched, to
complete a task has several obvious benefits that are well
documented by others. When working with large code
bases, the downfalls of an all-in-one approach, such as an
IDE, become a bit clearer. A system such as the FreeBSD
kernel is already several hundred megabytes of text.
Processing that code base with tools such as Cscope and
global in order to make it more easily navigable generates
a further 175 MB of data. Although 175 MB of data may
be small in comparison with the memory of the average desktop or laptop, which routinely come with 2 GB
to 4 GB of RAM, storing all that state in memory while
processing leads to lower performance in whatever tool is
being used. The pipeline processing of data, which keeps
in-memory data small, improves the responsiveness
of the tools involved. Loading the FreeBSD kernel into
Eclipse took quite a long time and then took up several
hundred megabytes of RAM. I have seen similar results
with other IDEs on other large code bases.
An even larger challenge looms for those who work on
not only large but also heterogeneous code bases. Most
Web sites today are a mélange of PHP or Python with C or
C++ extensions, using MySQL or PostgreSQL as a database back end, all on top of an operating system written
in C. It is often the case that tracking down particularly
difficult problems requires crossing language barriers
several times—from PHP into C++ and then into SQL,
then perhaps back to C or C++. Thus far, I have seen no
evidence of tools that understand how to analyze these
cross-language interactions.
The area that deserves the most attention is visualization. Of all the tools reviewed, only Doxygen generates
interesting and usable visual output. The other tools
have a very narrow, code-based focus in which the user is
usually looking at only a small part of the system being
investigated.
Working in this way is a bit like trying to understand
the United States by staring at a street sign in New York
City. The ability to look at a high-level representation of
the underlying system without the fine details would be
perhaps the best tool for the code spelunker. Being able
to think of software as a map that can be navigated in
different ways—for example, by class relations and call
graphs—would make code spelunkers far more productive.
more queue: www.acmqueue.com
One last area that has not been covered is the network. Network spelunking, the ability to understand an
application based on its network traffic, is still in a very
nascent state, with tools such as Wireshark being the state
of the art. Many applications are already running online,
and being able to understand and work with them at the
network level is very important. Q
REFERENCES
1. Cscope man page; http://cscope.sourceforge.net/
cscope_man_page.html.
2. Doxygen Web site; http://www.stack.nl/~dimitri/
doxygen/.
3. GNU global source-code tag system (Apr. 21, 2008).
Tama Communications Corporation; http://tamacom.
com.
4. gprof; http://www.gnu.org/manual/gprof- 2. 9.1/gprof .
html.
5. Graphviz Web site; http://www.graphviz.org/.
6. Jones, T., Tauferner, A., Inglett T. 2007. HPC system
call usage trends. Linux Clusters Institute; http://www.
linuxclustersinstitute.org/conferences/archive/2007/
PDF/jones_21421.pdf.
7. ktrace: standard tool on open-source operating systems.
8. Neville-Neil, G.V. 2003. Code spelunking: Exploring
cavernous code bases. ACM Queue 1( 6): 42-48. http://
doi.acm.org/10.1145/945131.945136.
9. Sun Microsystems. 2005. How to Use DTrace; http://
www.sun.com/software/solaris/howtoguides/dtrace-howto.jsp.
10. Sun Microsystems. 2005. Solaris Dynamic Tracing
Guide; http://docs.sun.com/app/docs/doc/817-6223.
11. Truss is available on Solaris.
12. Wright, G.R., Stevens, W.R. 1995. TCP/IP Illustrated,
Vol. 2: The Implementation. Boston, MA: Addison-Wesley Professional.
LOVE IT, HATE IT? LET US KNOW
feedback@acmqueue.com or www.acmqueue.com/forums
GEORGE V. NEVILLE-NEIL ( gnn@acm.org) is a columnist
for Communications of the ACM and ACM Queue, as well as a
member of the Queue Editorial Board. He works on networking and operating system code and teaches courses on various subjects related to programming.
© 2008 ACM 1542-7730 /08/1100 $5.00
This article appeared in print in the October 2008 issue of
Communications of the ACM.
ACM QUEUE November/December 2008 33
