﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Dave commented on NH Prof: Performance implications for the profiled application</title><description>I've put the NHibernate.Initialize() call in a #if block. Personally I don't care that while profiling Nhibernate the application is slower than usual. When I'm done profiling I simply remove the conditional symbol "DEBUG_NHIBERNATE". 
  
  
Let me put it this way. If after each NHibernare profiling session, a slow application is the only thing that takes time, I'm very, very, very happy. But mostly I have to remind developers that certain habbits don't do well when it's come to performance.
  
  
A faster profiling session would I consider as a bonus, not as a must.
</description><link>http://ayende.com/3872/nh-prof-performance-implications-for-the-profiled-application#comment4</link><guid>http://ayende.com/3872/nh-prof-performance-implications-for-the-profiled-application#comment4</guid><pubDate>Mon, 16 Feb 2009 08:22:19 GMT</pubDate></item><item><title>Gabriel N. Schenker commented on NH Prof: Performance implications for the profiled application</title><description>I have identified the same problems in one of my legacy apps. When NHProf was active the application was REALLY slow! I have not mesured the difference but out of my feeling I would say at least a factor of 3 to 5 slower than without NHProf. Please note: it is a legacy app and has many "sub-optimal" queries (n+1 and the like).
  
I'll give the new version a try as soon as possible! I still think that NHProf ROCKS!!!
</description><link>http://ayende.com/3872/nh-prof-performance-implications-for-the-profiled-application#comment3</link><guid>http://ayende.com/3872/nh-prof-performance-implications-for-the-profiled-application#comment3</guid><pubDate>Sun, 15 Feb 2009 08:51:55 GMT</pubDate></item><item><title>Ayende Rahien commented on NH Prof: Performance implications for the profiled application</title><description>Kyle,
  
The problem is how do you identify the key :-)
</description><link>http://ayende.com/3872/nh-prof-performance-implications-for-the-profiled-application#comment2</link><guid>http://ayende.com/3872/nh-prof-performance-implications-for-the-profiled-application#comment2</guid><pubDate>Sat, 14 Feb 2009 14:51:18 GMT</pubDate></item><item><title>Kyle Szklenski commented on NH Prof: Performance implications for the profiled application</title><description>That's pretty awesome. I love stories of good optimization, because I used to be in charge of profiling and identifying bottlenecks at a previous company. It was incredibly fun, and they had incredibly high restrictions on how fast things had to be and so forth. Hm, I thought I'd written a post at my blog about the two main ways of optimizing, but I can't seem to find it. Oh well. Probably most of the people who read your blog are familiar with them anyway!
  
  
By the way, would it be possible to cache the StackTrace object? I am not sure what you'd use for the key, but it seems like if you were getting calls to the GetStackTrace in the same exact positions, it's gonna have the same or very similar StackTrace objects every time. Just a thought, and maybe not a good one!
</description><link>http://ayende.com/3872/nh-prof-performance-implications-for-the-profiled-application#comment1</link><guid>http://ayende.com/3872/nh-prof-performance-implications-for-the-profiled-application#comment1</guid><pubDate>Sat, 14 Feb 2009 14:43:37 GMT</pubDate></item></channel></rss>