|
Log in |
FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
![]() Hi Per,
I'm working my way through the different components of the Suite. As I'm new to all this, I don't understand the significance of all the information. I've watched the recording of the Lachlan's Sydney presentation, but unfortunately your answers to questions did not get recorded. When I select viewing Optimization Candidates, which columns are important in determining what could be optimized ? I understand cyclometric complexity is important, but I don't know which other columns give information that might suggest work needs to be done, and what sort of values would cause concern. Some of the columns I am curious about are Dup Calls, Dependencies, Tail Calls. TIA, Sue |
#2
|
|||
|
|||
![]() Sue King wrote:
> Hi Per, > > I'm working my way through the different components of the Suite. As > I'm new to all this, I don't understand the significance of all the > information. I've watched the recording of the Lachlan's Sydney > presentation, but unfortunately your answers to questions did not get > recorded. > > When I select viewing Optimization Candidates, which columns are > important in determining what could be optimized ? I understand > cyclometric complexity is important, but I don't know which other > columns give information that might suggest work needs to be done, and > what sort of values would cause concern. > > Some of the columns I am curious about are Dup Calls, Dependencies, > Tail Calls. > > TIA, > > Sue Sue, Some of these view definitions are a bit dated. "Optimization Candidates" is currently defined as showing the methods/functions/procedures where - there are loops present, and also one of - word overrides are present (those used to be slow but not so much on recent CPUs) - legacy instructions are present ('loop', BCD instructions, et al) - there are more than 32 direct references (sub-routine call sites) - there are more than 16 indirect references (virtual method call sites) - there are value copies (i.e. non-const parameters of non trivial size) - there are indirect variable references (i.e. all references to a particular variable immediately follow a pointer within what the first variable points to (slow)) - there are more than 4 inside stack references (i.e. locals that did not fit in available registers) - there are more than 4 outside stack references (i.e. parameters that did not fit in available registers) - there are more than 50 dependencies (i.e. more than 50 case of read or write contention a.k.a. back-to-back instructions that read to or write from the same register(s), which can cause stalls). Like cyclomatic complexity, many of these metrics have to do with general code complexity. The more complex a routine is, the less efficient it tends to be (not to mention harder to understand for humans, typically). "Dup calls" is a rough measure of how much code appears to do roughly the same work. This can sometimes be optimized by lifting the common logic into a separate helper routine. Tail calls are Call instructions immediately followed by a Ret instructions - those can be pulled together in a Jmp instruction but only if you are coding at the asm level, of course. I am not even sure this optimization is such a great idea anymore with the call/return history that CPUs maintain nowadays. Note generally that there's a popup hint on every column in the view header that attempts to give a brief description. IHTH Per |
#3
|
|||
|
|||
![]() Per Larsen wrote:
> Sue King wrote: > > > Hi Per, > > > > I'm working my way through the different components of the Suite. > > As I'm new to all this, I don't understand the significance of all > > the information. I've watched the recording of the Lachlan's Sydney > > presentation, but unfortunately your answers to questions did not > > get recorded. > > > > When I select viewing Optimization Candidates, which columns are > > important in determining what could be optimized ? I understand > > cyclometric complexity is important, but I don't know which other > > columns give information that might suggest work needs to be done, > > and what sort of values would cause concern. > > > > Some of the columns I am curious about are Dup Calls, Dependencies, > > Tail Calls. > > > > TIA, > > > > Sue > > Sue, > > Some of these view definitions are a bit dated. > > "Optimization Candidates" is currently defined as showing the > methods/functions/procedures where > > - there are loops present, and also one of > > - word overrides are present (those used to be slow but not so much on > recent CPUs) > - legacy instructions are present ('loop', BCD instructions, et al) > - there are more than 32 direct references (sub-routine call sites) > - there are more than 16 indirect references (virtual method call > sites) - there are value copies (i.e. non-const parameters of non > trivial size) - there are indirect variable references (i.e. all > references to a particular variable immediately follow a pointer > within what the first variable points to (slow)) > - there are more than 4 inside stack references (i.e. locals that did > not fit in available registers) > - there are more than 4 outside stack references (i.e. parameters that > did not fit in available registers) > - there are more than 50 dependencies (i.e. more than 50 case of read > or write contention a.k.a. back-to-back instructions that read to or > write from the same register(s), which can cause stalls). > > Like cyclomatic complexity, many of these metrics have to do with > general code complexity. The more complex a routine is, the less > efficient it tends to be (not to mention harder to understand for > humans, typically). > > "Dup calls" is a rough measure of how much code appears to do roughly > the same work. This can sometimes be optimized by lifting the common > logic into a separate helper routine. > > Tail calls are Call instructions immediately followed by a Ret > instructions - those can be pulled together in a Jmp instruction but > only if you are coding at the asm level, of course. I am not even sure > this optimization is such a great idea anymore with the call/return > history that CPUs maintain nowadays. > > Note generally that there's a popup hint on every column in the view > header that attempts to give a brief description. > > IHTH > > Per I'm finding the tools interesting, and have some comments about them, but they will have to wait until after I come back from holidays. Thanks for the detailed explanations. The hints sometimes take a while to show, and some columns seem to be missing them. I look for them now though, and they are helpful. Regards Sue |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Ann: Insider - new Nexus Quality Suite tool | Eivind Bakkestuen [NDD] | nexusdb.public.announcements | 0 | 23rd September 2014 12:58 AM |
Ann: Insider - new Nexus Quality Suite tool | Eivind Bakkestuen [NDD] | nexusdb.public.support | 0 | 23rd September 2014 12:46 AM |
Ann: Insider - new Nexus Quality Suite tool | Eivind Bakkestuen [NDD] | nexusdb.public.support.qualitysuite | 0 | 23rd September 2014 12:46 AM |