Initial Impressions of UberProf, Part 2

In a previous post, I talked about the first 30 minutes or so of working with the various parts of UberProf.  It’s been a bit longer, so I wanted to update some of that.


Previously, I noted the following:

“Since it is long before I care about profiling this app (since it is a test database used to satisfy my specs), I won’t go into much of the details, but one interesting thing I noticed is that, in a routine where I am doing naughty N+1 things in a loop, it only flags the last three selects as N+1, even though all six are identical (except for the values in the where clause).  I’m going to have to keep an eye on this.”

I can update that by noting that this is per design.  Let me digress as I am wont to do.

What counts as ‘bad’ when it comes to profiling SQL statements is, to a certain extent, context-dependent.  Ayende (and whomever else) designed the profilers to note things as alerts based on their experience.  But, he also made a number of them configurable.  The Select N+1 alert is one of those configurable items.  The ‘naughty’ things I was doing happened to be in a loop where there were six of them. The first three did not get alerts in the UI, the last three did.  Well, as it turns out, the configurable piece of this was very clearly set to only start to mark an alert on the fourth item, and so the UI did exactly as it was configured to do.

IF (and this is a big if) the end user (me) thought that this setting should be on the first Select N+1 or the 97th, then I could have done so.  Once I set it to alert on the 1st Select N+1 (as a test), it did so.

What I like about this is that the profiler will always (well, it should, see below for more) profile every call, and allow me to set some settings to the levels that I prefer.  It’s up to me to decide those levels.  In other words, the tool allows me to put in my own expectations.

In my mind, this is a very good thing.


Things get a little more rocky here.

As the previous post noted, the profiler didn’t work on my L2S web app.  It either threw an error (using the v4 dll) or didn’t profile (using the non-v4 dll), neither of which was a good thing.

After mailing the issue to the Google support list and not getting a response in a day or so (I think), I did email Ayende directly, after which all communication has been through the support list.

<digression>This should be taken with a large grain of salt, but it was a bit troubling that the initial message made it through proper moderation but didn’t get action until I emailed Ayende.  I believe he happened to be in the midst of travelling as he always does, so I understand it, but it was troubling, not so much to me personally, since I knew it would be addressed, but more to the business partners I’m working with, who don’t know Ayende, don’t know Alt.NET, etc.  This is something that is endemic to ‘smallish’ support, and something I am very painfully aware of.  Unless I am personally working on a support issue, various external groups don’t necessarily know that their questions have been acknowledged.  To be perfectly clear, with large support groups, you often have the reverse issue, where you might get some immediate acknowledgement that your support question has been noticed, but you don’t know if there is an actual human being working on it till it works through whatever internal ticketing/queuing system they happen to have.</digression>

The long and the short of the whole shooting match is that my code was creating L2S data contexts in a way that was different from the standard way of doing it (I am overriding the standard constructor), and once I made that clear, Ayende was able to give clear and explicit instructions of something I needed to change in my code base, while also fixing the “security transparent method” error I was getting on his end with a new build.  (Note: As I’m writing this, there may be a lingering issue, but I’ll leave that to another post if it really is an issue).

Having said that, there was some ‘broken window’ problems.  To use an analogy, in NYC, at some point, there was a crackdrown on addressing broken windows.  Though I completely leave aside the question of the efficacy of the thing, the idea was that if the authorities in Times Square started to address issues like broken windows, real serious crime would also go down because of the added focus.  An individual broken window isn’t a serious crime issue, but if it is addressed as one, then there’s an expectation that serious crimes would be addressed.

All of the profiler tools have a notification when a new build is available.  Within L2SProf, when you clicked on the notification, the app crashed.  This is not a confidence builder.  It’s a broken window.  “If the new build notification process doesn’t work, what else doesn’t work?”  It’s a simple thing, one might say a trivial thing, but it does make a difference.

Now that I’ve said all that, let’s get to the good stuff. 

Once the profiler started working, it immediately raised very clear and targeted alerts about what could be improved.  Having only worked with it for an hour, these alerts seem to me to be spot on and accurate.  There are very clear improvements that can be made to my app and how I coded various methods.  This is exactly why I bought the thing.

Quick Summary

The process by which I got the L2SProf app to work was a bit less smooth than I would have liked.  If I had not bought the thing and just done the trial, I probably would not have made the purchase but put it on the back-burner.  Since I had bought the thing, having worked through the initial difficulties, it seems to be worth the price.

I plan on posting a before and after comparison post once I analyze some data further.  I am encouraged by what I see so far.

posted on Friday, August 27, 2010 9:06 PM Print
No comments posted yet.

Post Comment

Title *
Name *
Comment *  
Please add 2 and 1 and type the answer here: