1

I'm currently trying to profile a way too slow usecase where the CPU spend most of its time in the EntityFramework.ni.dll module.

Unfortunatly as it's a .ni.dll, I don't have the related PDB file, so VS can't associate function calls inside it to the corresponding source code.

I saw on SO there is a way to build it back, but it takes to have the corresponding EntityFramework.pdb file and I don't have a clue on how to spot that file on my system anyway.

On the other hand I saw that I do have several EntityFramework.PDB files here and there.

So I'm wondering if there is a way to prevent usage of .ni.dll during profiling / debugging sessions thanks a VS configuration option or such ?

Please notice that right now the reference to the EntityFramework in my project is coming from the corresponding NuGet package and I'd rather avoid changing anything at this level if possible.

I agree that if such a trick exist, it will result in loading a distinct module than the one the performence trouble have been spoted. But I hope it can at least help me either diagnose the trouble if it's still slow or to spot where to find the original EntityFramework.dll thanks to Module window at debug time.

Thanks in advance for your help ! ;)

Lemmy
  • 291
  • 2
  • 12
  • Not a very sensible request, you use a profiler to find out how you can improve **your** code. When you find out that the bottleneck is *not* in your code then you are done. Making EntityFramework related code faster requires a better dbase engine, smaller queries or better table indexes. – Hans Passant Nov 28 '16 at 11:10
  • @HansPassant : I can't figure out how 99% of the CPU time can be spent in this layer knowing what is doing my code. I took good care of logging SQL requests between IIS and Sql Server in order to be certain I'm optimising several N+1 database access antipattern thanks usage of Include and EF Lvl 1 cache. Thus, since this optimisation, I can tell for sure that neither the database engine the queries or the table indexes are suspect anymore. – Lemmy Nov 28 '16 at 14:15
  • WPR generaes PDBs for .ni.dlls during capturing of a trace. which profiling tool do you use? – magicandre1981 Nov 29 '16 at 05:06
  • @magicandre1981 I'm using VS 2015>Analyze>Performence profiler. I've indeed spoted a EntityFramework.ni.pdb on my OS : I guess it must be the result of one of my several profiling attempts. But still : 1) during the report loading, logs explicitly state that symbols loading fails for all EntityFramework related modules, 2) I can walk down the call tree up to EntityFramework.ni.dll, but not further, except when they are dynamicClass.lambda_method call in it. 3) none of those lines give access to the associated code. 4) I can't find a way to link EF module to its code directory I got from github – Lemmy Nov 30 '16 at 09:57
  • @magicandre1981 : I forgot to mention that when I go down the call tree, once inside the EntityFramework module, there is no function names, what seems to highlight the fact the symbol loading step failed, no matter the initial "update" entry I've read about VS profiler [here](https://blogs.msdn.microsoft.com/visualstudioalm/2012/12/10/creating-ngen-pdbs-for-profiling-reports/) – Lemmy Nov 30 '16 at 10:17
  • try WPR and not VS. Install WPT, part of Windows 10 SDK (https://dev.windows.com/en-us/downloads/windows-10-sdk), open a CMD.exe as admin, run this command **wpr.exe -start CPU -start DotNET && timeout -1 && wpr.exe -stop C:\HighCPUUsage.etl**, wait a few seconds to capture some CPU usage of your tool, press a key to stop logging. Now analyze the ETL in WPA: https://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-42-WPT-CPU-Analysis – magicandre1981 Nov 30 '16 at 16:14
  • do you get a PDB for the the ni version of EF when you use WPR? do you see good stacks in WPA? – magicandre1981 Dec 02 '16 at 15:38
  • @magicandre1981 : Thanks for the tips. This tool is really cool. But unfortunately either I didn't found how to do it or it's not possible to have the tool jumping to the source code. Notice I've been playing around with it long enough to see it produce the EntityFramework.ni.pdb file I'm looking for when I request symbols loading. Placing it into my VS symbols cache make things better when profiling with VS as i can step down the call tree within EntityFramework. But according to what display VS, this pdb file only contain function names, not source code line numbers ... – Lemmy Dec 02 '16 at 16:27
  • @magicandre1981 : so basically it's helping a lot to get much closer to where the hot spot is, even if it's within EntityFramework, but having only the call stack is not enough to have a good understanding of the global mechanic that cause the slowdown without been able to debug step by step within this hotspot zone. – Lemmy Dec 02 '16 at 16:38
  • @magicandre1981 : My guess is that, due to the process of a GUID been produced and stored within both related EF.dll and EF.pdb, I need to produce myself (I.E using NGen) a .ni.pdb file with source code line numbers. Thus it must take to have the corresponding EF.pdb file, that I can't get from NuGet. My best option is to get EF code, compile it, and have my project depending on it instead of NuGet EF package ... quite complex :D I wonder if there is a pdb + source extra download option in NuGet somewhere, even if I guess it wouldn't solve my trouble if EF team doesn't ship them with the dll – Lemmy Dec 02 '16 at 16:43
  • WPA has no source linking information.There is already a workitem for providing PDBs: https://entityframework.codeplex.com/workitem/386 but nothing happened. You can compile EF6 code on your own and add your self compiled version to the project, now you have your PDBs: https://github.com/aspnet/EntityFramework6/tree/6.1.3 – magicandre1981 Dec 03 '16 at 08:12

0 Answers0