From Joseph.Francis@fmr.com Thu Apr 20 16:29:40 2000 From: "Francis, Joseph" To: "'Bob Lechner'" , "Francis, Joseph" Subject: RE: Test Planning Progress: Using GPROF - a good idea - where's the data? Date: Thu, 20 Apr 2000 16:28:40 -0400 RJLRef: $CASE/bdelog2ks/bdeGprof_jfr.2k0420 I'll have to analyze the bottom section of your response later, but to get the meaningful information from GMON.OUT, I actually had to type GPROF BDE if I recall correctly. GPROF was then smart enough to take the raw data from GMON.OUT and produce quite a useful report from it. My full report for the week will include a meaningful GPROF report attached. Joe Francis (7-6710) > -----Original Message----- > From: Bob Lechner [SMTP:lechner@cs.uml.edu] > Sent: Thursday, April 20, 2000 4:23 PM > To: Joseph.Francis@fmr.com > Cc: jfeinber@jupiter.cs.uml.edu; joseph.francis@fmr.com; > jfrancis@jupiter.cs.uml.edu; she@jupiter.cs.uml.edu; > ntansala@jupiter.cs.uml.edu; pshaughn@mediaone.net; > maushah@jupiter.cs.uml.edu; lechner@jupiter.cs.uml.edu > Subject: Re: Test Planning Progress: Using GPROF - a good idea - > where's the data? > > Joe, your gprof results will be very interesting. > I looked for your profile data but didn't find it. > $CASE/bdelog2ks/jfrancis/bde/src/gmon.out looked > like raw or setup data from gprof but not for bde. > > I would not rely on gprof alone for ANY code removal - since > (1) test tracers can reveal actual calls but not potential ones; > (2) code reachability is configuration dependent. > > However, by revealing what functions (or lines of code) > are executed or not, [g]prof can focus our visual inspections > and keyword searches to verify likely targets for code removal. > > Bob lechner > > > P.S. > Re: test coverage, here are the counts of table rows > in your test_data/test*.dat files. They show that the test*.dat > files contain rows frm all bde table types. > > From bdelogs of pr_set actions we can see what field types > are explicitly updated during bde test runs. > > From bde state transitions on stdout during tests we can see control flow > at the state-box level. In principle, this is where all the action > (method) calls are made. State changes can also be logged, transparently > by genlog's generic pr_set macros, if we always use pr_set to change > state > and make state a global static attribute in a new schema table (e.g. > GA for Global Attributes). > > ------------------------------------------------- > saturn.cs.uml.edu(78)> grep '(^ HG00)' *.dat|wc > 12 96 1698 > saturn.cs.uml.edu(79)> grep '(^ HN00)' *.dat | wc > 30 450 4872 > saturn.cs.uml.edu(80)> grep '(^ HL00)' *.dat | wc > 20 120 1208 > saturn.cs.uml.edu(81)> grep '(^ HP00)' *.dat | wc > 40 280 2616 > saturn.cs.uml.edu(82)> grep '(^ HI00)' *.dat | wc > 10 110 1544 > saturn.cs.uml.edu(83)> grep '(^ HA00)' *.dat | wc > 80 880 13932 > saturn.cs.uml.edu(84)> grep '(^ CG00)' *.dat | wc > 20 140 1388 > saturn.cs.uml.edu(85)> grep '(^ GX00)' *.dat | wc > 20 270 4848 > saturn.cs.uml.edu(86)> grep '(^ FO00)' *.dat | wc > 0 0 0 > saturn.cs.uml.edu(87)> grep '(^ XB00)' *.dat | wc > 0 0 0 > saturn.cs.uml.edu(88)> pwd > /nfs/jupiter/proj3/case/bdelog2ks/jfrancis/testing/test_data > saturn.cs.uml.edu(89)> > ------------------------ > There is partial data on function pairs (call occurrences) > on a per-module basis from manual inspections in > It could be cross-checked with gprof outputs. > > > > > I am planning to make a more complete report for the week and send > > it out tonight, but I wanted to let the group know the main progress I > made > > this week, which was effectively using GPROF. > > > > Among the various tests we want to conduct is a "code coverage" test > > in which we find out which functions are actually being called and which > are > > not. I started trying to figure this out by analyzing source code. > After > > about two hours of that, I realized that it would take me several months > > work to do it that way, so I followed Prof. Lechner's suggestion and > tried > > to use GPROF. I'll include all the details in my main progress report > for > > the week, but I wanted to let everyone know that it was trivially easy > to > > get a listing of every function called by BDE, both for libraries being > > linked in and functions internal to BDE. All I had to do was relink > with a > > -pg flag, run BDE, shut down BDE, and the report that I needed was > output to > > a file. It couldn't have been simpler. > > > > This will be an effective means of doing two things: > > > > (1) Identifying "dead" code that can be removed from BDE. > > (2) Assessing the effectiveness of individual tests in > > exercising sections of BDE code. > > > > > My main plan for the next week is to continue to work with GPROF > and > > > use of BDE to develop a regression test or set of individual > regression > > > test cases that will give us a reliable means of testing all of BDE's > > > functionality. > > > > > Joe Francis > > (508-787-6710) > >