Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.misc Subject: Re: Basics of Program Design Message-ID: <463@proxftl.UUCP> Date: 13 Jul 88 05:23:08 GMT References: <807@vax.UUCP> <440@proxftl.UUCP>Distribution: na Organization: Proximity Technology, Ft. Lauderdale Lines: 30 In article , webber@aramis.rutgers.edu (Bob Webber) writes: ) In article <440@proxftl.UUCP>, bill@proxftl.UUCP (T. William Wells) writes: ) < On UNIX, there is also another program `tcov' which is also ) < useful. This program gives you the number of times that each ) < statement of a program is executed. While this does not tell you ) < how long the statements took, it does give you a good idea where ) < to look for inefficiencies. ) ) Err, tcov was actually designed for something slightly different, test ) coverage analysis. The idea is that you might want to test out all that ) spiffy code to make sure it works and tcov would tell you which chunks ) of code your tests haven't yet executed. Good point, and one I did not think of since my mind was on tools for execution time optimization. I personally do not often use tcov for this purpose because my debugging techniques usually have me hand step through each line of the program. Of course, some programs are so complex that this is not practical, e.g., a parser I wrote recently; then I used tcov. ) Believe it or not, alot of ) commericial code makes it out the door with remarkably few execution ) paths tested (for that matter, alot makes it out the door with known ) bugs because of deadlines, but that is another matter, at least it ) runs fast, sometimes). Unfortunately, that is all too true. Here we try to check all the possibilities in the code, though we do not mandate use of tcov. And, we have had to ship code with known bugs, though they are usually of the "this feature is not present" variety. That's life in the deadline-ridden world. Ugh.