I'm working on a review of the new Nexus Quality Suite, which I'll be posting as soon as I've finished it. I just wanted to write a quick post about a very simple topic, that I think might be a good question for every delphi shop's developers, and every single-person delphi developer to think about:
Can you afford NOT to answer any of these questions?
1. What is the slowest function in my application? (Total CPU seconds spent while doing some particular sequence of commonly used features)
2. What function is called most often in my application, perhaps thousands or millions of times, perhaps even unnecessarily? (Function X calls function Y, in a tight loop, burning CPU, and something calls function X more often than necessary.)
3. Do I have any memory leaks? Are any heap memory areas being written to after they are freed?
4. Are there errors in my code that the Delphi compiler and its hints and warnings can't show me, that could be found easily by static analysis?
5. What is your largest module (lines of code)? What is your longest and most complex, and most potentially buggy function?
If you need answers to #1, and #2, and I think most developers do need answers, then you need a profiling tool.
If you need answers to #3, you need something of a heap debug session, either FastMM in Full Debug Mode, or something equivalent.
If you need answers to #4, you need something of a "LINT" tool, either CodeHealer, or Pascal Analyzer.
If you need answers to #5, and you're on XE8, you have Castalia, which will help you find functions that could be the most complex, or largest, or the largest units, in your application. There are also some answers to related questions in the Audits and Metrics feature built into higher SKUs of Delphi.
What other questions should every Delphi developer ask about her codebase, and what tools do you recommend to find the answers to those important questions?
Can you afford NOT to answer any of these questions?
1. What is the slowest function in my application? (Total CPU seconds spent while doing some particular sequence of commonly used features)
2. What function is called most often in my application, perhaps thousands or millions of times, perhaps even unnecessarily? (Function X calls function Y, in a tight loop, burning CPU, and something calls function X more often than necessary.)
3. Do I have any memory leaks? Are any heap memory areas being written to after they are freed?
4. Are there errors in my code that the Delphi compiler and its hints and warnings can't show me, that could be found easily by static analysis?
5. What is your largest module (lines of code)? What is your longest and most complex, and most potentially buggy function?
If you need answers to #1, and #2, and I think most developers do need answers, then you need a profiling tool.
If you need answers to #3, you need something of a heap debug session, either FastMM in Full Debug Mode, or something equivalent.
If you need answers to #4, you need something of a "LINT" tool, either CodeHealer, or Pascal Analyzer.
If you need answers to #5, and you're on XE8, you have Castalia, which will help you find functions that could be the most complex, or largest, or the largest units, in your application. There are also some answers to related questions in the Audits and Metrics feature built into higher SKUs of Delphi.
What other questions should every Delphi developer ask about her codebase, and what tools do you recommend to find the answers to those important questions?
We need better and smarter Refactoring tools! Imagine for example a Refactoring tool which automatically splits a complex and long procedure into smaller routines in one step. Or a Refactoring tool which automatically splits large modules into smaller units by using Artificial Intelligence. Or a smart Refactoring tool which automatically corrects code issues found by Pascal Analyzer.
ReplyDeleteOr maybe you just need better programmers.
ReplyDeleteRefactoring tools are there to help programmers not to replace them.
Sorry Colin, your statement is not very smart. The things I suggested are in fact HELPING programmers by saving time which then can be invested in even more programming. So Smart Refactoring is a booster for PRODUCTIVITY.
ReplyDeleteThe kinds of problems that Pascal Analyzer can detect can not normally be automatically corrected. For example, imagine you have a function that allocates a value on the heap and returns it as a result. That means every caller of the function must free the memory allocated by the function. Since there is no way for Pascal Analyzer to know that this is not a leak it will report it as one. It would be extremely difficult, although perhaps not impossible to automatically refactor code written this way.
ReplyDeleteThere IS some possibility to both write "detect a problem and automatically fix it" for some things. In the Java world for example, this kind of "detection plus automatic or semi-automatic repairs" exists within tools like IntelliJ IDEA.
Of course not every problem could be fixed by automatic Smart Refactoring. However, there is still the word "semi-": IMO, there is still room for smarter Refactoring.
ReplyDeleteI used Peganza in the past (2006ish) to quick get a feel for a new large source dumped on me. Just playing with the reports to get a feel of the modularity of the codebase. (which units/classes are entangled with what etc).
ReplyDeleteMaybe that could be attempted using code metrics too, with distance plots etc.