Line level timings not rendered properly over RDP in APP 8.5

Bart Read

Hi,


I've just noticed that the rendering of line level timings in the source code view appears to be broken, at least when running over RDP:

- There are no bar charts in the Avg Time and Time columns,
- There are no red markers rendered to the right of the vertical scrollbar

This makes it difficult and error prone to find the slowest lines of code in certain types of file - for example, MVC views - if they're even modestly large. (I'm doing some consultancy and a few of my client's pages are *very* slow to load.)

I don't know whether this happens when NOT running over a remote desktop connection.

System details:

- ANTS Performance Profiler 8.5
- Windows Server 2008 R2 SP1
- Profiling ASP.NET MVC 4 app running on IIS port 80 (restart required)

Also, just spotted another bug: the source code view has a maximum height set when you undock it. Since there's currently no visual indication of where the slowest lines are I want to be able to make the source code window as large as possible - ideally the size of my screen - but am unable to do this because of the maximum height setting.

Hope this is useful for you.


Thanks,


Bart

Jessica R

Hi Bart!

There aren't any issues I'm aware of with profiling over RDP--I suspect the issue may be either with the machine itself or something strange about the results so that the heat maps aren't appearing, but have you been seeing this issue on other machines you've remoted into?

Regarding the maximum height setting on the source view window, I've logged a feature request (PP-3517) to let it go full screen--thanks for the suggestion!

Bart Read

Thanks Jessica. The machine's running Windows Server 2008 R2 SP1, in case that's any help?

Jessica R

Hi Bart!

I tried to repro this by remoting into a Win2k8 R2 SP1 machine and a few other OS''s but the heat maps still worked alright. Would you be able to check if this still happens on the machine when not connected via RDP?

Bart Read

Thanks Jessica,


I've seen it happen on Windows Server 2008 R2, Windows Server 2012, Windows 8, and Windows 8.1, both over RDP and locally. I demonstrated the problem, which is extant in the latest release, for Ben the other lunchtime.

What seems to be happening is that the bars in the timing columns, and the lines in the navbar on the right, are being normalised against the overall timings for the period selected in the timeline, NOT against the longest running line in the file. This is a problem because if, for example, you're looking at wall clock time, the real performance problems are generally not in the supposedly most expensive stack trace (which is often something like "waiting for synchronization").

As I say the issue is that you have to find the most expensive lines of code by inspection, which is obviously error prone, not to mention time-consuming for larger source files.

Hope that's helpful.


Thanks,