jim@aurora.UUCP (Jim Veitch) (04/11/89)
Sender: info-1100-request@cis.ohio-state.edu Date: 6 Apr 89 17:27:27 PDT (Thursday) Subject: Re: grapher package written in CLX? From: "Larry_Masinter.PARC"@xerox.com To: cox@renoir.Berkeley.EDU Cc: info-1100@sumex-aim.stanford.edu In-Reply-To: cox%renoir.berkeley:EDU:Xerox's message of 26 Mar 89 22:42 PST While imitation is the sincerest form of flattery, the graphical statistical profiler in Composer seems to be missing some of what I thought were key elements of SPY: a) thresholding Eliminate from the display those functions responsible for less than a given percentage of the time. This is important to reduce the complexity of the display. I agree. I actually tried the your idea with somewhat disappointing results (for the grapher -- but the tty version uses it still). Maybe the implementation I tried lacks sophistication. Equally important is reducing clutter by excluding extraneous processes and hiding system or other functions. The current profiler has the philosophy "better too much than too little", and you can reduce complexity by scrolling to the right place. This is clearly one place things can be improved. b) merging Flexible control over merging information about the same function when it appears in different parts of the graph. This is already present. How flexible do you want it? Currently I just combine all occurrences of a function in a graph into a single root & display a new graph. I'd be curious to know how your algorithm differs from ours; ours is very simple. c) rerooting the ability to obtain sub-trees with more detail than the main graph. This is already present (though "with more detail" is currently moot). d) visual display of importance Making the height of the boxes proportional to the percentage of time seemed to work OK as a way of giving a quick visual indication of what functions were really important. It is hard to see that 73 and 78 and are a lot closer than 37 and 87. I tried a few experiments here, including the height idea. The main problem seems to be related to the complexity of the graph; if it's too complex, varying box heights just makes it worse. We ended up going with positional cues instead: branches in the graph where time is spent appear above sibling branches where less time is spent. This seems to work OK once you get used to it. I think only merging is tricky -- I spent a couple of weeks trying to get the algorithm right. Its tricky mainly because of recursive merging.