funny - Programming Blog

Archive for the ‘funny’ Category

Compiled or Bust?

20 Mar 2010

While I may have mixed emotions toward LINQ to SQL, we’ve had great success with it on Stack Overflow. That’s why I was surprised to read the following:

If you are building an ASP.NET web application that’s going to get thousands of hits per hour, the execution overhead of Linq queries is going to consume too much CPU and make your site slow. There’s a runtime cost associated with each and every Linq Query you write. The queries are parsed and converted to a nice SQL Statement on every hit. It’s not done at compile time because there’s no way to figure out what you might be sending as the parameters in the queries during runtime.

So, if you have common Linq to Sql statements like the following one ..
var query = from widget in dc.Widgets
            where widget.ID == id && widget.PageID == pageId
            select widget;
var widget = query.SingleOrDefault();
.. throughout your growing web application, you are soon going to have scalability nightmares.

J.D. Conley goes further:

So I dug into the call graph a bit and found out the code causing by far the most damage was the creation of the LINQ query object for every call! The actual round trip to the database paled in comparison.

I must admit, these results seem … unbelievable. Querying the database is so slow (relative to typical code execution) that if you have to ask how long it will take, you can’t afford it. I have a very hard time accepting the idea that dynamically parsing a Linq query would take longer than round-tripping to the database. Pretend I’m from Missouri: show me. Because I am unconvinced.

All of this is very curious, because Stack Overflow uses naive, uncompiled Linq queries on every page, and we are a top 1,000 website on the public internet by most accounts these days. We get a considerable amount of traffic; the last time I checked it was about 1.5 million pageviews per day. We go to great pains to make sure everything is as fast as we can. We’re not as fast as we’d like to be yet, but I think we’re doing a reasonable job so far. The journey is still very much underway — we realize that overnight success takes years.

Anyway, Stack Overflow has dozens to hundreds of plain vanilla uncompiled Linq to SQL queries on every page. What we don’t have is “scalability nightmares”. CPU usage has been one of our least relevant constraints over the last two years as the site has grown. We’ve also heard from other development teams, multiple times, that Linq to SQL is “slow”. But we’ve never been able to reproduce this even when armed with a profiler.

Quite the mystery.

Now, it’s absolutely true that Linq to SQL has the performance peculiarity both posters are describing. We know that’s true because Rico tells us so, and Rico … well, Rico’s the man.

In short the problem is that the basic Linq construction (we don’t really have to reach for a complex query to illustrate) results in repeated evaluations of the query if you ran the query more than once.

Each execution builds the expression tree, and then builds the required SQL. In many cases all that will be different from one invocation to another is a single integer filtering parameter. Furthermore, any databinding code that we must emit via lightweight reflection will have to be jitted each time the query runs. Implicit caching of these objects seems problematic because we could never know what good policy is for such a cache — only the user has the necessary knowledge.

It’s fascinating stuff; you should read the whole series.

What’s unfortunate about Linq in this scenario is that you’re intentionally sacrificing something that any old and busted SQL database gives you for free. When you send a garden variety parameterized SQL query through to a traditional SQL database, it’s hashed, then matched against existing cached query plans. The computational cost of pre-processing a given query is only paid the first time the database sees the new query. All subsequent runs of that same query use the cached query plan and skip the query evaluation. Not so in Linq to SQL. As Rico said, every single run of the Linq query is fully parsed every time it happens.

Now, there is a way to compile your Linq queries, but I personally find the syntax kind of … ugly and contorted. You tell me:

Func<Northwinds, IQueryable<Orders>, int> q =
     CompiledQuery.Compile<Northwinds, int, IQueryable<Orders>>
                ((Northwinds nw, int orderid) =>
                            from o in nw.Orders
                            where o.OrderId == orderid
                            select o );

Northwinds nw = new Northwinds(conn);

foreach (Orders o in q(nw, orderid))
{
}

Anyway, that’s neither here nor there; we can confirm the performance penalty of failing to compile our queries ourselves. We recently wrote a one time conversion job against a simple 3 column table containing about 500,000 records. The meat of it looked like this:

db.PostTags.Where(t => t.PostId == this.Id).ToList();

Then we compared it with the SQL variant; note that this is also being auto-cast down to the handy PostTag object as well, so the only difference is whether or not the query itself is SQL.

db.ExecuteQuery(
   "select * from PostTags where PostId={0}", this.Id).ToList();

On an Intel Core 2 Quad running at 2.83 GHz, the former took 422 seconds while the latter took 275 seconds.

The penalty for failing to compile this query, across 500k iterations, was 147 seconds. Wow! That’s 1.5 times slower! Man, only a BASIC programmer would be dumb enough to skip compiling all their Linq queries. But wait a second, no, wait 147 seconds. Let’s do the math, even though I suck at it. Each uncompiled run of the query took less than one third of a millisecond longer.

At first I was worried that every Stack Overflow page was 1.5 times slower than it should be. But then I realized it’s probably more realistic to make sure that any page we generate isn’t doing 500 freakin’ thousand queries! Have we found ourselves in the sad tragedy of micro-optimization theater … again? I think we might have. Now I’m just depressed.

While it’s arguably correct to say that every compiled Linq query (or for that matter, any compiled anything) will be faster, your decisions should be a bit more nuanced than compiled or bust. How much benefit you get out of compilation depends how many times you’re doing it. Rico would be the first to point this out, and in fact he already has:

Testing 1 batches of 5000 selects 


uncompiled  543.48 selects/sec
compiled    925.75 selects/sec



Testing 5000 batches of 1 selects



uncompiled  546.03 selects/sec
compiled    461.89 selects/sec

Have I mentioned that Rico is the man? Do you see the inversion here? Either you’re doing 1 batch of 5000 queries, or 5000 batches of 1 query. One is dramatically faster when compiled; the other is actually a big honking net negative if you consider the developer time spent converting all those beautifully, wonderfully simple Linq queries to the contorted syntax necessary for compilation. Not to mention the implied code maintenance.

I’m a big fan of compiled languages. Even Facebook will tell you that PHP is about as half as fast as it should be on a good day with a tailwind. But compilation alone is not the entire performance story. Not even close. If you’re compiling something — whether it’s PHP, a regular expression, or a Linq query, don’t expect a silver bullet, or you may end up disappointed.

[advertisement] JIRA 4 – Simplify issue tracking for everyone involved. Get started from $10 for 10 users.

Go to Source

No Comments
Tags: code execution, linq, mixed emotions, public internet, query object, sql statement, stack overflow, widget, Widgets

The Non-Programming Programmer

In: funny| programming

13 Mar 2010

I find it difficult to believe, but the reports keep pouring in via Twitter and email: many candidates who show up for programming job interviews can’t program. At all. Consider this recent email from Mike Lin:

The article Why Can’t Programmers… Program? changed the way I did interviews. I used to lead off by building rapport. That proved to be too time-consuming when, as you mentioned, the vast majority of candidates were simply non-technical. So I started leading off with technical questions. First progressing from easy to hard questions. Then I noticed I identified the rejects faster if I went the other way – hard questions first – so long as the hard questions were still in the “if you don’t know this then you can’t work here” category. Most of my interviews still took about twenty minutes, because tough questions take some time to answer and evaluate. But it was a big improvement over the rapport-building method; and it could be done over the phone.

After reading your article, I started doing code interviews over the phone, using web meetings. My interview times were down to about 15 minutes each to identify people who just can’t code— the vast majority.

I wrote that article in 2007, and I am stunned, but not entirely surprised, to hear that three years later “the vast majority” of so-called programmers who apply for a programming job interview are unable to write the smallest of programs. To be clear, hard is a relative term — we’re not talking about complicated, Google-style graduate computer science interview problems. This is extremely simple stuff we’re asking candidates to do. And they can’t. It’s the equivalent of attempting to hire a truck driver and finding out that 90 percent of the job applicants can’t find the gas pedal or the gear shift.

I agree, it’s insane. But it happens every day, and is (apparently) an epidemic hiring problem in our industry.

You have to get to the simple technical interview questions immediately to screen out the legions of non-programming programmers. Screening over the telephone is a wise choice, as I’ve noted before. But screening over the internet is even better, and arguably more natural for code.

I still wasn’t super-happy with having to start up the web meeting and making these guys share their desktops with me. I searched for other suitable tools for doing short “pen-and-paper” style coding interviews over the web, but I couldn’t find any. So I did what any self-respecting programmer would do. I wrote one.

Man, was it worth it! I schedule my initial technical screenings with job applicants in 15-minute blocks. I’m usually done in 5-10 minutes, sadly. I schedule an actual interview with them if they can at least write simple a 10-line program. That doesn’t happen often, but at least I don’t have to waste a whole lot of time anymore.

Mike adds a disclaimer that his homegrown coding interview tool isn’t meant to show off his coding prowess. He needed a tool, so he wrote one — and thoughtfully shared it with us. There might well be others out there; what online tools do you use to screen programmers?

Three years later, I’m still wondering: why do people who can’t write a simple program even entertain the idea they can get jobs as working programmers? Clearly, some of them must be succeeding. Which means our industry-wide interviewing standards for programmers are woefully inadequate, and that’s a disgrace. It’s degrading to every working programmer.

At least bad programmers can be educated; non-programming programmers are not only hopeless but also cheapen the careers of everyone around them. They must be eradicated, starting with simple technical programming tests that should be a part of every programmer interview.

[advertisement] JIRA 4 – Simplify issue tracking for everyone involved. Get started from $10 for 10 users.

Go to Source

No Comments

Welcome Back Comments

In: funny| programming

13 Feb 2010

I apologize for the scarcity of updates lately. There have been two things in the way:

Continuing fallout from International Backup Awareness Day, which meant all updates to Coding Horror from that point onward were hand-edited text files. Which, believe me, isn’t nearly as sexy as it … uh … doesn’t sound.
I am presenting and conducting a workshop at Webstock 2010 in New Zealand. This is a two week trip I’m taking with the whole family, including our little buddy Rock Hard Awesome, so the preparations have been more intense than usual.

On top of all that, according to the program, I just found that my presentation involves interpretive dance, too. Man. I wish someone had told me! My moves are so rusty, they’ve barely improved from Electric Boogaloo. But hey, at least I don’t have to sing Andrews Sister songs like poor Brian Fling.

And then, of course, there’s that crazy Stack Overflow thing I’m always yammering on about. Very busy there, our team is expanding, and we have big plans for this year, too.

But, there is hope!

Thanks to the fine folks at Six Apart — and more specifically the herculean efforts of one Michael Sippey — Coding Horror is now hosted in the TypePad ecosystem. Which means, at least in theory, better “cloud” type reliability in the future. (cough)

One accidental bit of collateral damage was that comments, by necessity, were disabled during this two month period. At first, I was relieved. This may seem a bit hypocritical, since I originally wrote A Blog Without Comments is Not a Blog. And I still believe it too. But as I prophetically noted in the very same post:

I am sympathetic to issues of scale. Comments don’t scale worth a damn. If you have thousands of readers and hundreds of comments for every post, you should disable comments and switch to forums, probably moderated forums at that. But the number of bloggers who have that level of readership is so small as to be practically nil. And when you get there, believe me, you’ll know. Until then, you should enable comments.

I guess you can put this in the “nice problems to have” category, but let me tell you, it’s not so nice of a problem when it’s on your plate. At a large enough scale, comments require active moderation or they rapidly go sour. People get mean, the crazies come out in full force, and the comments start to resemble an out of control trailer park reality show brawl. It’s fun, I suppose, but in a way that drives out all the sane people. Left unchecked, the best you can hope for is to end up head resident at the sanitarium. And that’s a hell of a way to go out.

(the above is from Mike Reed’s amazing Flame Warriors series, by the way. Well worth your time if you haven’t seen it already.)

The degeneration of comments was a shame, because it undermined my claim that comments are awesome.

It’s an open secret amongst bloggers that the blog comments are often better than the original blog post, and it’s because the community collectively knows far more than you or I will ever know.

The best part of a blog post often begins where the blog post ends. If you are offended by that, I humbly submit you don’t understand why blogs work.

Why would I have bothered to found Stack Overflow with Joel Spolsky if I didn’t believe in the power of community — that none of us is as dumb as all of us? Honestly, a lot of the design of Stack Overflow comes from my personal observations about how blog comments work. But my creaky old Coding Horror comments offered none of the fancy voting and moderation facilities that make Stack Overflow work. And without ample free personal time and attention from me to weed the comment garden, the comments got out of control.

Most of all, I blame myself.

I got some amazing emails in lieu of comments on my last few blog posts, and it positively kills me that these emails were only seen by two sets of eyes instead of the thousands they deserve. That’s a big part of why I hate email silos. And really, email in general.

But there was another unanticipated side effect of having comments disabled that Stéphane Charette pointed out to me in email.

Here is an interesting “silver lining” to the crash you had. Without
comments, it forces us, your faithful readers, to think more about
what you have to say.

In a way, things are back to how your blog used
to be. In recent years, the huge influx of comments means that we —
or just I? — end up spending 1/4 of my time reading what you wrote,
and then merging in what everyone else wrote. Depending on how I feel
about the topic and your approach to the issue, the weight values may
be very different than 50/50. But regardless, I always have to
consider when clicking on my Coding Horror bookmark: “Is now the
right time to check if he has a new entry? Do I have enough time to
read through a hundred comments? Should I wait until later tonight
when the kids are in bed to go read his latest article?”

I never thought about it until recently. Your crash is what brought
this up to light. Like tonight, when I saw your new headline in my
iGoogle page, I didn’t have to consider whether or not it was the
right time. I read the article, and then thought for myself. I
didn’t let other people’s comments steer my thoughts. How nice!

I’m not certain why it works like this. Often, the sheer number of
comments distracts from what you wrote, but for some reason, it is
impossible not to at the very least scroll through what people say.
In a way, your blog has ended up like a slashdot article, with a
paragraph or two of content at the top, and then everyone wanting to
insert their $0.02.

Thinking for yourself. Now there’s a novel idea. In the reverberating echo chamber that is the internet, I think we would all do well to remind ourselves of that periodically.

He’s also right that the psychic burden of all those comments was weighing not just on readers, but on me, the writer, too. That’s why I had a false sense of freedom when comments were disabled. You mean I can say whatever I want, and nobody can contradict me underneath my very own post? Revolutionary!

There are some absolute gems of insight and observation in comments, but sometimes extracting them was too much like pulling teeth. At the same time, I felt obligated to read all the comments on every post of mine. If I was asking people to read the random words I’m spewing all over the internet, how could I not extend my commenters the same courtesy? That’s just rude.

It seems the only thing worse than comments being on was comments being off. It started to feel empty. As if I was in an enormous room, presenting to an eerily mute audience.

So, while I am very glad to have comments back, and I welcome dialog with the community, there will be … changes. For the benefit of everyone’s mental health.

No more anonymous comments. While I would prefer to allow anonymous comments, it is clear that at this scale I don’t have time to deal properly with anonymous comments. If you want to say something, you’ll need to authenticate. If what you have to say isn’t worth authenticating to post, it’s probably best for both of us if you keep it to yourself anyway.

The good news is that the TypePad commenting system supports a veritable laundry list of authentication mechanisms — OpenID (naturally), Twitter, Facebook, Google, Yahoo, and many others. So authenticating to post a comment should only present a mild, but necessary, barrier to conversation.
Comment moderation will be more stringent. If you don’t have something useful and reasonably constructive to say in your comment, it will be removed without hesitation. You can be as critical of me (or, better still, my arguments and ideas) as you like, but you must convince me that you’re contributing to the conversation and not just yelling at me or anyone else.

I’m not looking for sycophants, but shrill argument is every bit as bad. When you comment here, try to show the class something interesting they can use. That’s all I’m asking.

It feels good to be back. Thanks to Six Apart for making it happen.

And, most of all, thanks to you for reading.

[advertisement] JIRA 4 – Simplify issue tracking for everyone involved. Get started from $10 for 10 users.

Go to Source