Call Graph - Build 491. [WOW]

• 
  Hi Paul,
  
  thanks for your comments. For your info:
  exclude system methods: Probably not going to happen in terms of hiding them completely or collapsing them but the ability to reduce their impact visually (by fading out or possibly drastically by size) is being worked on at the moment so should be in the next build.
  see multiple graphs side by side: wasn't planned and I'm not sure how useful that would be if the graphs are large? We are planning multiple graphs but not on screen at the same time.
  create a new graph from a method in existing graph: coming soon
  jump to code from graph: coming soon
  see parameters passed through (popup when req. not all time): might be easy enough to sort out for you as a toggle option perhaps, i'll ask about it
  be able to mark boxes with my own colour (tracing etc): had the same idea myself yesterday. Might be possible but wasn't in the immediate plans.
  expand all: we aren't going to allow that in case we hit a method with some obscene number of levels which would probably crash the profiler due to the memory demands it would create. We have come up with a reasable compromise of expanding a path by large chunks (not sure yet what the level will be but should be more than enough). This capping should allow you to expand paths quickly and safe guard the memory usage.
  collapse all: coming soon
  filter events: wasn't too sure what you mean regarding the call graph here (or are you referring to the events bar?)
  
  If any one else is reading this and has used the new call graph then please let us know what you think of it. We are trying to get as many opinions on it as possible.
  
  I'd also be really interested in hearing about how or what you would primarily use it for. If you wish to email your comments instead of posting on the forum then you can email: usability@red-gate.com and put "ANTS 4 Feedback" in the subject line.
  
  Regards,
  
  Stephen

  StephenC June 28, 2008 05:17

  - 0 +
• 
  Hi Stephen,
  
  Thanks for the positive response.
  
  with multiple charts, I was not looking to have multiple on screen at same time, more just that I could switch between and create new from a set point (both of which you have said will be coming)
  
  filter events : what I was looking to do, instead of trying to 'hide' boxes, was just be able to apply a filter that would change the opacity or size of certain events, pretty much like what you have said about the system events, it would be good just to be able to say 'show all _AfterEdit' methods or 'show all _CalcFormulaResult', then everything else pails into insignificance, and if you implement the fading scenario for system events, then it should just be an extension of that.. (sorry Bart). If you can think back to the tests we did it would help me do is see what recursion is happening quickly.
  
  other thing I thought about today . . . . is it possible to provide a 'suggestive' function that can identify code portions that can be streamlined,
  
  in my case . . .
  
  example #1:
  List(of <T>), could be replaced with HashTable, this alone has improved performance significantly.
  
  example #2:
  GetOrdinal --- there were over 700,000 calls to this system event at a cost of between 20-30%, certainly, changing this to an Enum of field position is going to be a good saving.
  
  What I am asking . . . is there a way to get a report to show some key bottlenecks (or am I just being tooooooo lazy ?
  
  looking forward for next installment.

  Lexicon June 28, 2008 05:54

  - 0 +

Add comment

Please sign in to leave a comment.