How to hide source for methods

Code profiling for .NET developers.

Moderators: AndrewH, melvyn.harbour, james.billings, Laura Morley, dene.boulton

How to hide source for methods

Postby kellystuard » Tue May 29, 2012 7:05 pm

I have a large code base that takes advantage of AOP (aspect oriented programming). I would like to hide the impact of a particular method.

As I'm currently showing just "Methods with source", I'm hoping there's some way to compile my solution such that the profiler cannot find the source for that particular project. I've attempted compiling just that project in release mode, to no avail.
kellystuard
 
Posts: 6
Joined: Tue May 29, 2012 7:00 pm

Postby james.billings » Tue May 29, 2012 7:48 pm

Thanks for your post.

It's an interesting one this - usually people are concerned when the Profiler *can't* find their source code!

There's no option I can think of to not show source for any specific method.

The Profiler utilises the PDB's to try to locate the source, so removing these may help - but that's global to each assembly rather than giving you any level of control, and in any case, the latest version offers integrated decompilation so you could reconstruct the source even where it not available anywhere (useful for 3rd party DLLs for example)
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby kellystuard » Tue May 29, 2012 8:34 pm

Indeed. I'm sure mine's not the normal case. I'm mainly just interested as it showing up as: "Collapsed methods without source. To view these methods, [blah, blah]".

Building in release mode took care of the .pdb file not being built, anymore. Even with that, it's still showing the source. It's not just showing the decompiled source; it's showing the source code (with comments, and everything).

I was under the impression that with no .pdb files, it would treat it as it would any other 3rd-party dll (e.g. NHibernate). However, it's somehow being really smart (good for it; bad for me) in locating the source files.
kellystuard
 
Posts: 6
Joined: Tue May 29, 2012 7:00 pm

Postby kellystuard » Tue May 29, 2012 8:40 pm

So somehow it's figuring out where the source code is located. Perhaps the dll has references to where it was compiled.

I renamed the folder that the project is in and re-ran the profiler. Now the profiler doesn't list the methods in the project.

I appreciate the tenacity of the profiler when it goes to find source. I would appreciate it more if I could tell it to ignore certain items. Now that I can "hack" to tell it not to look at something, it's not such a big deal. It would be a great feature to add, though.
kellystuard
 
Posts: 6
Joined: Tue May 29, 2012 7:00 pm

Postby james.billings » Tue May 29, 2012 8:42 pm

I don't think we cache the PDB's anywhere - but if there's a copy in your PATH anywhere, or they've been added to the GAC somehow it'll probably still find them. Also if you're profiling directly from the build output it /may/ (I'd need to check) automatically find the source code there.

What kind of application is it?
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby kellystuard » Tue May 29, 2012 8:52 pm

It's a solution with a web application project and quite a few class library projects.

So it was compiled in [say] F:\\source and installed to [say] C:\\Inetpub\\dest.

Profiling settings are:
"ASP.NET web application (IIS)"
ASP.NET web application (URL): "http://www.example.com/"
Profile on: "Original Port (IIS will restart)"

Hitting a method that it can find source for gives [say] the following:
F:\\source\\classlibrary\\foo.cs

This happens for both dll's that have associated pdb's and those that don't. The only way [I've found] to stop that is to delete the original source directory. If i were a betting man, I'd say that one of the dll's with pdb's is storing the path to the non-pdb'd one.
kellystuard
 
Posts: 6
Joined: Tue May 29, 2012 7:00 pm

Postby james.billings » Tue May 29, 2012 8:54 pm

I guess that's possible - you could always open up one of the remaining PDB files and see if you can spot it referenced anywhere (some source code paths appear in plain text for some of mine...)
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby kellystuard » Tue May 29, 2012 9:08 pm

Nope. Nothing references this project, directly (AOP). I grep'd the pdb's and, while there are other references, none to the dll in question.

I'm just going to go with profiler being relly smart. If it's of interest to your group, I can put together a minimalist example. Otherwise, I'm going to go on with my life.
kellystuard
 
Posts: 6
Joined: Tue May 29, 2012 7:00 pm

Postby dene.boulton » Tue May 29, 2012 10:41 pm

Hello,

The current Early Access Program (EAP) builds for the Performance Profiler implement filtering that can be defined by the user.
When viewing the Call-Tree or Method Grid, right-click on a method and the context menu will show some options for defining filters (e.g. Show Only Blah, Hide BlahFoo).

The EAP page is here: http://help.red-gate.com/help/ANTSPerfo ... d_eap.html

Hope this helps.
Dene Boulton
Red Gate
dene.boulton
 
Posts: 53
Joined: Wed Oct 12, 2011 12:44 pm
Location: Cambridge

Postby kellystuard » Tue May 29, 2012 10:59 pm

That's exciting! I'll check it out.
kellystuard
 
Posts: 6
Joined: Tue May 29, 2012 7:00 pm


Return to ANTS Performance Profiler 7

Who is online

Users browsing this forum: No registered users and 0 guests