2

With a 150 *.dll ASP.NET website that's precompiled (updatable), what are some possible causes for a '% Time in JIT' that is often quite high (> 60%) and fluctuating long after the application has warmed-up (all functionality accessed) and without app restarts or file changes that might generate new assemblies?

One would expect that the machine code generated for all assemblies would be re-used for the duration of that app-domain. Is there a finite size to the volume of machine-code that's cached? Under what scenarios would the same assembly need to be re-JIT'd in the same app domain? Or is it necessarily the case that new assemblies are being generated? Do factors such as memory pressure impact this performance counter?

Reference:

Nariman
  • 6,368
  • 1
  • 35
  • 50
  • regular expressions generate assemblies behind the scenes, if these are constantly re-created that could be a contributing factor... – Jason D Nov 26 '09 at 03:54

2 Answers2

1

It could be anything that does assembly emit. Linq Expressions compile, or regular expressions, that are not being cached correctly.

George Polevoy
  • 7,450
  • 3
  • 36
  • 61
  • Indeed. You have to be /really/ careful with regular expressions: sometimes they can leak. See http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=692 for examples of how to pre-compile and cache them. – Jeremy McGee Dec 21 '09 at 04:11
0

If you are setting cache parameters, you may be inadvertently disabling the precompiled server-side cache. Take a look at this article:

http://codeclimber.net.nz/archive/2007/04/01/Beware-the-ASP.NET-SetCacheability-method.aspx

umbyersw
  • 585
  • 5
  • 12