.vb & .ascx code?

mwinner

Hello,

I've noticed that Profiler does not automatically decompile .vb and .ascx files, and when you have it do so, it does not give you a line-by-line summary, hence making it hard to find any bottlenecks located in those files.

Am I missing something?

Thanks!

Jessica R

Thanks for your post!

It sounds like there may be an issue with your pdb files (if the profiler successfully finds a pdb file, the methods from that assembly will come up as bold in the call tree) ...

Could you kindly see if the tips in this Troubleshooting PDB Problems article help?
http://documentation.red-gate.com/displ ... B+problems

mwinner

Hi Jessica,

Thanks for the reply and the docs. I've tried that out (gone through the pages so there is no debug=true), and still no luck (I'm using asp.net, btw). If I want to see the ascx page (ASP.MassActions3 in attachment), I have to decompile using Reflector, which doesn't give the whole picture.

I've placed a screenshot at: http://goldbug.eu/Ants1.gif

As you can see, I'm trying to figure out why listTickets.aspx is taking so long to load. listTickets.aspx is calling a ascx page and that's where things are starting to get fuzzy. As you can see, we have a few places that are getting hit thousands of times and it's starting to add up, but I can't seem to see WHERE.

Any help would be appreciated... especially since the trial is running out tomorrow, and if I can solve this I can get the boss to by it

Thanks!

Jessica R

Hi mwinner,

So sorry for the delay!

I'll shoot you an email with a trial extension key so you can continue testing, though after some investigation, I don't know if it will be possible to get the line-level timings for the user controls...

This article explains what may be happening.. http://www.red-gate.com/supportcenter/c ... 0707000060

"ASP .NET has a class called "FastObjectFactory" that may compile your ASCX code and cache the assembly, eliminating the references to your source code, causing the "profile only methods that contain source code" option to filter the ASCX method calls from the results."

So because FastObjectFactory may be making the ASCX method calls seem to be without source, the profiler is not able to calculate the line-level timings for them

mwinner

Hi Jessica,

Thanks for the reply (I understand delays) and thanks for the extension, though I believe the boss decided to go buy it any hows (no complaints!).

It's a tad frustrating, since some of my major code are in these files. I guess if worse came to worse, I can move some of them into regular .aspx files and test from there. (Is there any way to bypass the FasObjectFactory?)

I know there's a 'workaround' posted, but that doesn't give all the details needed. Any chance on putting this on the 'next version wish list'?

Thank you for the help!

Jessica R

Hi mwinner,

Glad to hear he still likes the tool!

I'm not too familiar with FastObjectFactory myself so I'm not sure of a way to bypass it and my googling hasn't been of much help either unfortunately. Also, I'm afraid the workaround is just to get the methods from the ascx files to show up in the call tree (by setting the filter "all methoids" instead of "methods with source") but this still wouldn't show the line-level timings in the source code view when decompiled.

I'm not sure if this is something we'd be able to fix but I've logged issue PP-3399 for it so we can at least look into it a bit more--thanks for posting about this!

mwinner

Great!

Thanks for the update!