User profile for James Moore

Hi Clayton, Sorry you have had these problems. The behaviour you are describing can happen for several reasons. In ANTS Profiler 3 we only sample the CPU speed once, modern CPU's have a tendency to change speed to save power and this can throw out the numbers shown in the UI when we convert from clock ticks to seconds. The second reason for this can be if you have a very tight loop the profiler's overhead calculations can get skewed and once again we can display a slightly odd number. The relative speeds of methods/lines will be accurate though. The final reason for this happening is if you have several threads all calling that method where by the total wall clock time can end up being greater than the total runtime (3 threads running for 5 seconds = 15 seconds even if the app is only running for 5 seconds in total). If your problem is due to either of the first two reasons (or you are just curious) you might want to give our Early Access Program of ANTS Profiler 4 a try: http://www.red-gate.com/messageboard/viewforum.php?f=80. There are some quite radical changes to the profiler in there and fixes for many of the problems caused by newer CPU's. We would love any feedback about ANTS Profiler 4 you have.. Hope this helps, James / comments

Hi Clayton, Sorry you have had these problems. The behaviour you are describing can happen for several reasons. In ANTS Profiler 3 we only sample the CPU speed once, modern CPU's have a tendency to...

0 votes

Ahh Sorry Paul, My mistake - it was added to the installer just after the latest released build. When I will email you oveer the copy of the dll for now and we should have another build out early next week with it in. James / comments

Ahh Sorry Paul, My mistake - it was added to the installer just after the latest released build. When I will email you oveer the copy of the dll for now and we should have another build out early n...

0 votes

Hi Paul, Thanks for the feedback again, and I'm glad you like the events bar. I'm sure that Stephen will want to follow up on your other comments but I wnated to let you know we now ship a dll with the profiler (RedGate.Profiler.UserEvents.Dll) which you can reference from your code and generate manual events which should hopefully appear on the timeline. It would be great if you could give it a go and see if it works for you. As always thanks for your help, James / comments

Hi Paul, Thanks for the feedback again, and I'm glad you like the events bar. I'm sure that Stephen will want to follow up on your other comments but I wnated to let you know we now ship a dll with...

0 votes

Hi There, You are best of talking to our sales team (sales@red-gate.com) and they will be able to ensure this happens when you buy ANTS 3 (You will need a suport and upgrades contract). If you need any further assistance please let me know, James / comments

Hi There, You are best of talking to our sales team (sales@red-gate.com) and they will be able to ensure this happens when you buy ANTS 3 (You will need a suport and upgrades contract). If you need...

0 votes

Split into new topic.. James / comments

Split into new topic.. James

0 votes

Hi Jonathan, Thanks for your comments, First let me address your requests for ANTS Profiler 4: (1) ability to attach the profiler to a running process This will not be supported in ANTS Profiler 4. It was a very difficult decision to make as it is somthing which is requested fairly regularly but the limitations it would have placed on us would have stopped us doing a lot of the things we wanted to. In a little more depth: There are two (sensible) ways to profile a .NET application when writing a profiler the first is is "sample" the application every x ms and see what its doing - this will lead to the lowest overhead but the results returned will be significantly less accurate as you only have partial data about the run. The second method is to "instrument" the application - this is where you change the application when it is JIT compiled though a hook the Microsoft makes available so that it fires events when certain things happen. This is the approach we take as it provides more complete data but overhead can be more of a problem (something we have worked very hard to reduce in V4). This approach also requires us to [re]start the application so that we can register our handlers with the .NET framework and hook into the JIT Compilation phase. I have not looked into it directly but one of our customers told me that Yourkit takes a third approach which, when evaluating the possibilities for V4, I did not feel happy with. What Yourkit apparently do is register their hooks system wide so that they profile every .NET process on the machine regardless of if you want it profiled or not and "attach to process" just makes the profiler start reporting results. I think they might have some stuff in there to minimise the impact when you are not attached (or at least I hope they do!) but I didn't feel happy following them down this route of loading ourselves into every .NET process as the moment you load the profiler it changes how function calls are handled in the CLR and thus possibly altering the behaviour of the application on that machine, something I would strongly discourage on production systems. (2) remote profiling capability (e.g., VS remote debugging tools I do not think this will make it into 4.0 but it is certainly on our list for future versions. Would this be less useful without the attach to process funcationality? (3) a low-overhead profiling mode for long-running profiling We offer 3 modes of profiling in Version 4 with varying levels of overhead. The overhead has been significantly reduced in comparison to any other instrumenting profiler on the market in V4 and hopefully those 3 modes should provide you with the flexibility that you need. If the profiler overhead is still too high with "Methods with source code mode" please let us know as one of our main aims has been to remove as much overhead as possible. Sorry for a not very positive reply [image] We are seriously considering point 2 for future versions. I doubt that point 1 will every be supported via the UI but we might at some point put it in for power users to use but I would want them to be aware of what they are doing first [image] Thanks once again for the feedback, James / comments

Hi Jonathan, Thanks for your comments, First let me address your requests for ANTS Profiler 4: (1) ability to attach the profiler to a running process This will not be supported in ANTS Profiler ...

0 votes

Hopefully tomorrow or early next week. We have most of the engine code done and just need to update the UI to allow access to it all. I will post in this thread once we have released the build. James / comments

Hopefully tomorrow or early next week. We have most of the engine code done and just need to update the UI to allow access to it all. I will post in this thread once we have released the build. James

0 votes

Please use Build 308 / comments

Please use Build 308

0 votes

Hi, Thanks for the feedback again - I asked around about this yesterday, the responsiveness problem seems to be related to the number of points on the timeline and its redraw rate, we should get this fixed before the final release (hopefully a lot sooner [image] ) I'm not 100% sure this will work but in the short term zooming in on the timeline (the mouse wheel is the only way this functionality is exposed right now) might well help cut down the amount of CPU being used by the UI. I think that Jason, Usman and Stephen are working on trying to reproduce an inhouse test case similar to your code to try and reproduce the other behaviour you are seeing. With respect to the view not changing or updaing then this could well be due to the processing time required to build up the different trees.. I think in the original build we released there were no "green spinnys" showing processing progress - I'm not sure they are all in the new build but there are a few more in there... Equally the lack of results changing could well be down to some buggy code so I will ask our testers to look into this as well.. [image] Once again thanks for the bug reports and feedback - its all a great help, James / comments

Hi, Thanks for the feedback again - I asked around about this yesterday, the responsiveness problem seems to be related to the number of points on the timeline and its redraw rate, we should get th...

0 votes

Hi there, Thanks for the feedback! o) love the real time interactive time line, There is still quite a bit of work to do on it but glad you like it! o) at present A3 performs source only analysis in 6 secs (to preset point), A4 takes 20 seconds ? --> I promise not to do any more comparisons, as with the interactive time line, A4 already leaves A3 for dead. o) Time to load application still an issue: without profiler from launch to main screen being shown : 20 seconds, time when profiling (method and line level timings) : 1min 58 seconds, time when profiling (method level only with source ) : 1min 40 seconds. I'm not quite sure what would be happening here, one of the items at the top of our list for AP4 is reducing the profiler's overhead. Would you be happy for me to get one of our testers/developers to follow up with you on this so that we can understand what is going on? o) love the fact that showdialog methods do not get penalized as 'bottlenecks' o) Could someone please explain what (Thread Blocked) actually does We have started to monitor the amount of time a thread spends blocked, IE waiting on a monitor for disk io/user input etc - in wall clock time mode this wait time is included in time with children and shown in the treeview as (Thread Blocked). If you use the drop down in the bottom right (just above the source code view) you can switch to CPU time which will show how much time your thread spent executing on the CPU. o) the slowest methods are showing as (JIT overhead) in the grid, this is making tracing a little cumbersome, when using 'abridged' method, it just shows large bottlenecks as (no source available) The amount of time the framework spends Jitting your code is included in the tree view - this can be quite large, especially at start up but there is very little you can do about this other than run less code [image] I will get a tester/developer to follow up on the other point. o) I am not getting any Time (%) or Hit count in the source code viewer This sounds like a bug - does this happen consistently? Are your methods written in bold in the treeview? looking forward for the next build. . . There should be one out in the next 24 hours or so with some new goodies in.. Thanks once again for spending time to give us some feedback, James / comments

Hi there, Thanks for the feedback! o) love the real time interactive time line, There is still quite a bit of work to do on it but glad you like it! o) at present A3 performs source only analysi...

0 votes

How can we help you today?

James Moore

Comments