David Chapman - Chapman Consulting
I am an expert contract software developer in San Jose, California who has written over 1,000,000 lines of code in my 26 years of industry experience. I specialize in compute-intensive algorithms, Electronic Design Automation (EDA), and parsers/compilers.
I provide algorithm design, development, testing/debugging, and optimization services for high performance, high value, and high reliability software. If you don't know how to get your software project started, need help writing or testing it, or need to improve it, I can help.
After 1,000,000 lines of code, I've learned a few surprising things about writing quality software. I have written a series of essays about software development, testing, and optimization. A few are featured below. Read some of the essays, then call or write to find out how I can help you deliver code that works - and works well.
Software Development Done Right.
Zero Tolerance for Code Errors
- Details
- Last Updated on Sunday, 29 January 2012 07:58
"Do I Really Need to Fix Small Memory Leaks?"
Recently I was asked whether a few memory leaks were a problem. It depends, I said. Was the test case representative of how your program will run? If the program will never run for a long time, then maybe the errors are not serious.
When you run a leak analysis tool like valgrind or PurifyPlus from IBM/Rational, often the test case you choose is relatively small because these tools slow program execution considerably. The concern is that the memory leaks will continue as the program continues to run, and memory consumption will grow until serious problems (out of memory, page faulting) occur.
Optimizing with ^C
- Details
- Last Updated on Sunday, 29 January 2012 20:34
Quickly Getting Up to Speed
When you are asked to speed up a program, the temptation is to launch it using a runtime profiler such as gprof (the Free Software Foundation tool) or IBM's Rational Purify. Typically profilers instrument a program, then run it under the profiler's control. They may measure the length of time taken for each instruction sequence, or they may interrupt the program many times per second and count the number of times the program is in each portion of the code. They may even do both.
Runtime profilers can be very useful, but your program will run much slower under test than it normally would. For software that already takes minutes or hours, this can be quite a burden. There is additional overhead for function calls and returns, so well-structured code with many small functions may slow down still more.