Red Gate forums :: View topic - Line level timings not rendered properly over RDP in APP 8.5
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
ANTS Performance Profiler 8
ANTS Performance Profiler 8 forum

Line level timings not rendered properly over RDP in APP 8.5

Search in ANTS Performance Profiler 8 forum
Post new topic   Reply to topic
Jump to:  
Author Message
Bart Read



Joined: 31 Mar 2005
Posts: 978
Location: Cambridge, UK

PostPosted: Thu Mar 27, 2014 3:27 pm    Post subject: Line level timings not rendered properly over RDP in APP 8.5 Reply with quote

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
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 229

PostPosted: Sat Mar 29, 2014 1:02 am    Post subject: Reply with quote

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!
_________________
Jessica Ramos
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
Bart Read



Joined: 31 Mar 2005
Posts: 978
Location: Cambridge, UK

PostPosted: Wed Apr 02, 2014 10:55 am    Post subject: Reply with quote

Thanks Jessica. The machine's running Windows Server 2008 R2 SP1, in case that's any help?
_________________
Bart Read
Principal Consultant
bartread.com Ltd
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 229

PostPosted: Tue Apr 08, 2014 6:05 pm    Post subject: Reply with quote

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?
_________________
Jessica Ramos
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
Bart Read



Joined: 31 Mar 2005
Posts: 978
Location: Cambridge, UK

PostPosted: Thu Apr 24, 2014 7:39 pm    Post subject: Reply with quote

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,
_________________
Bart Read
Principal Consultant
bartread.com Ltd
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group