Ayende @ Rahien

Tom Marien commented on Challenge: Write the check in comment

Fri, 30 Oct 2009 12:24:44 GMT

I guess the comment counts for me then :P

Ayende Rahien commented on Challenge: Write the check in comment

Fri, 30 Oct 2009 12:00:25 GMT

Tom, UniqueResult will return null if nothing is matched

Tom Marien commented on Challenge: Write the check in comment

Fri, 30 Oct 2009 08:58:25 GMT

Comment : Did not slept well this night therefore i thought how i can screw up a working system. The GetEntryForSlug now can return null, instead of throwing an exception when nothing matched (before uniqueresult, now firstordefault) Kind regards

Patrik Hägne commented on Challenge: Write the check in comment

Thu, 29 Oct 2009 19:45:42 GMT

@Mike: I'm not sure you're serious, but I know for sure that there are a lot of developers out there that actually believe that to be true. The matter of fact is that in simple concatenation cases like this using a StringBuilder would be orders of magnitude slower.

Will Smith commented on Challenge: Write the check in comment

Mon, 19 Oct 2009 18:46:40 GMT

My logic may be slightly flawed, but it appears Martin and I are in agreement (well at least back in 2004) [martinfowler.com/.../...timizationRefactoring.html](http://martinfowler.com/bliki/IsOptimizationRefactoring.html)

Will Smith commented on Challenge: Write the check in comment

Mon, 19 Oct 2009 18:40:24 GMT

I knew that question would come up. Perhaps it's a stretch, but, I would say performance is the observable change in behavior here. To me refactoring follows prescribed methods of modifying the structure of the code and has no effect on the algorithms in place. In the case above it seems the algorithm has been changed to observe improved performance. I don't know, maybe Martin would ask what I've been smoking.

Ayende Rahien commented on Challenge: Write the check in comment

Mon, 19 Oct 2009 15:59:34 GMT

Will, What is the external behavior that was changed?

Will Smith commented on Challenge: Write the check in comment

Mon, 19 Oct 2009 15:53:37 GMT

I wouldn't call this a "refactoring" as there is a clear change in behavior. This is a rewrite (on a small scale). A refactoring is "restructuring an existing body of code, altering its internal structure without changing its external behavior." as defined by Martin Fowler. I would assume that said developer has a valid reason for this performance rewrite. neonp's "comment" seems the be the most accurate and concise.

neonp commented on Challenge: Write the check in comment

Mon, 19 Oct 2009 07:36:51 GMT

So obvious when working with ORMs : Improved performance from 2 queries to one.

Steve Py commented on Challenge: Write the check in comment

Sun, 18 Oct 2009 23:34:27 GMT

@ Nick, It's an assumption either way. Based on that type of behaviour and where that method would likely be called, my guess would be it would be expecting to find the real one at least 50% of the time. The higher the percentage, the less effective that optimization becomes, and at some point it becomes an averaged penalty. Still, my main point was that the re-factor hurt readability, and unless the gain was significant (i.e. noticable to the end user) then it wasn't worth it.

Phillip commented on Challenge: Write the check in comment

Sun, 18 Oct 2009 12:13:01 GMT

Actually I just realized why the result was retrieved first, so that the orderby/firstordefault could be used against the resulted list... Forget what I said I'm an idiot :)

Phillip commented on Challenge: Write the check in comment

Sun, 18 Oct 2009 12:09:57 GMT

I don't know what this is from or for, but could it not have been written like: private Entry GetEntryForSlug(string slug) { return session.CreateCriteria(typeof(Entry)) .Add( Restrictions.Like("Slug", slug) || Restrictions.Like("Slug", slug + "/default") ) .OrderBy(x => x.Slug.Length) .FirstOrDefault(); } If so then that's far more read-able than both the original and committed... And it's not retrieving the result before deciding what to do with it...

Nick Aceves commented on Challenge: Write the check in comment

Sun, 18 Oct 2009 10:48:26 GMT

@Steve, While the code could certainly be more clear, it would be naive to suggest that the performance improvement is negligible. Surely you're not suggesting that an extra filter condition and a Linq OrderBy cost more than another round trip to the database... To me, it really depends on how often we expect this code to load a default entry. If we are going to find real entry 90% of the time, I'd say leave the code as it was. If, instead, we're expecting to need a default entry around 50% of the time, and this code gets called frequently, then some kind of query optimization might make sense.

Steve Py commented on Challenge: Write the check in comment

Sun, 18 Oct 2009 07:08:23 GMT

I get what the re-factor is doing, though I can't say I agree with it. The original code is pretty clear exactly what it's doing. return the item, if not found return the default, if not found, return #null. If anything, my only concern might be that the code is doing more than "one thing." For instance it might be a bit of a nuisance after the fact to determine if you actually retrieved an item or ended up with a default. But that's a digress. The re-factor reduces the potential 2 queries to 1, however I'd say the readability of the intention of the code suffers. Get a list of the item an/or the item's default, then return the shortest one; assumed to be the item, if found, else the default, if found, else #null. The thing is it took a couple careful passes looking at that to be sure it didn't have a "gotcha" or difference in behaviour. Frankly I favor readability over sheer optimization unless performance is a significant issue. Even so, in the ideal case where the "real" item is found, the extra query condition and LINQ sort & extraction is itself imparting an extra performance cost. I doubt the gain on average is more than negligible if anything at all. Not sure what the actual choice in GIT comment ended up being, but I'd suggest that the following one should be an "Undo". ;)

tobi commented on Challenge: Write the check in comment

Sat, 17 Oct 2009 22:11:37 GMT

why would that be faster? it would be slower. comment: changed GetEntryForSlug to also return an entry for url with postfix "/default". first i try to find an entry that is an exact match for the slug. next i try it with a postfix. i ensured this by ordering by the length of the returned result list because the entry without postfix will be shorter and therefore first."

Mike commented on Challenge: Write the check in comment

Sat, 17 Oct 2009 21:54:11 GMT

He should use StringBuilder: var sb = new StringBuilder().Append("slug").Append("/default") .ToString() It would be faster. :)

JBland commented on Challenge: Write the check in comment

Sat, 17 Oct 2009 21:42:22 GMT

I've been bitten by this before. UniqueResult will throw an exception if the query returns more than 1 row, which is quite possible when using LIKE.

Chris Airey commented on Challenge: Write the check in comment

Sat, 17 Oct 2009 21:35:59 GMT

Maybe i'm wrong, but it doesn't like like neither of the queries are trying to archive the same result.

Matt commented on Challenge: Write the check in comment

Sat, 17 Oct 2009 20:36:43 GMT

I'd guess that it was rewritten to perform a single database query instead of unnecessarily performing two.

Mogens Heller Grabe commented on Challenge: Write the check in comment

Sat, 17 Oct 2009 20:33:42 GMT

Reduce number of potential queries by 50 %

Dmitry commented on Challenge: Write the check in comment

Sat, 17 Oct 2009 20:30:37 GMT

I assume the || operator is a bug. The committer was probably thinking about a LINQ-like optimization. Incidentally I did a very similar thing yesterday using Criteria lambda extensions. Instead of writing code like myCriteria.Add(p => p.FirstName == fname) .Add(p => p.LastName== lname) I wrote myCriteria.Add(p => p.FirstName == fname && p.LastName== lname) and it took me a minute to realize why I was getting a runtime exception.