Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Uber Prof New FeaturesGo To Session from alert

time to read 1 min | 144 words

Originally posted at 1/7/2011

This is another oft requested feature that we just implemented. The new feature is available for the full suite of Uber Profilers:

You can see the new feature below:


I think it is cute, and was surprisingly easy to do.

Uber Prof have recently passed the stage where it is mostly implemented using itself, so I just had to wire a few things together, and then I spent most of the time just making sure that things aligned correctly on the UI.

More posts in "Uber Prof New Features" series:

  1. (15 Jan 2011) A better query plan
  2. (14 Jan 2011) Go To Session from alert



I was waiting for this feature :)


Plz add auto-scroll list box to show the last item automatically.

Plz add clear/delete sessions/list to the toolbar not right click.

Plz create a multi-tab window for each time we start the new debug from vs.net. it makes tracking much easier.

Thanks for everything.


Not sure if it's possible but I would like to see how many times something was accessed from First Level Cache.

Ayende Rahien


That isn't really possible.

What scenario do you have in mind where this is actually interesting?


It was just something that came up in discussion today, we have some classes called KPIs which use similar data in order to generate stats and reports. One KPI would be to work out the scheduled cost for an employee to work, while another KPI is to work out the actual cost for an employee, for a week. Both KPI's happen to rely on a Job.

If the job has been loaded already for that request, each other employee doesn't query for that job since its in the first level cache, so 10 employees may happen to have the same job.

We were wondering if its possible to see cache hit counts vs actual queried result counts.

If that makes sense.

Ayende Rahien

It does make sense, but it would truly overload you with details that you usually don't need to see.

You can deduct that info from NOT seeing the query for it.


Most of the time we wouldn't need to see those details, you're right. But we were more wanting to ensure that the data was coming from the 1st level cache.

We are working on a legacy application that was started in .NET Beta, and all the data access is a mix of direct sql, table adapters, and a custom rolled data access generator. But we out grew all that, so we are rolling NHibernate to replace all that. (Reduced some sections from 2000+ queries down to like 6/7 with the help of eager loading, and requests from 7 seconds to 0.2)

When looking at the queries in NHProf, sometimes queries are duplicated and it's hard to figure out why. Other queries which we know are being called more than once only show in NHProf once so we know those are from 1st level cache.

So from this we discussed the possibility of seeing what duplicate queries were returning data from 1st level cache.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats