Monday night was a big night for us. Most notably, we started encrypting all data sent between our users' computers and the WebNotes server. In a perfect world, encryption would not affect the user experience at all; just make using WebNotes more secure. Privacy FTW!
Alas, this isn't a perfect world yet. 
The encryption algorithms must not only be implemented, but made very efficient. In algorithm terms (thanks, 6.046) that means they should run in O(n) time. With that goal in front of me, I started researching speedy yet still relatively secure encryption algorithms. I found the best candidate and went about implementing it in both JavaScript and C# so that our server and the user's browser will be "talking" with the exact same encryption scheme. Implementation was a surprisingly smooth process. Turns out that Ron Rivest (of RSA fame) et al. really know how to make simple yet elegant algorithms! After messages were encrypting & decrypting without any problems in a reasonable amount of time (~100ms in JavaScript to encrypt 30,000 characters), I patted myself on the back and ran it on the presses. After the new code went live, I made sure WebNotes still worked (it did) and called it a night.
Then, when I got to work this morning, things started to smell fishy. Our error logs were showing large numbers of request timeouts. Something was slowing down our server significantly. Requests were taking 10-30 seconds to process rather than the pre-encryption 200ms. As you could guess, server-side encryption was the culprit. Needless to say, I was very embarrassed that it was my code that was causing our users to endure 20+ second delays. That being said, I was also very confused as to why encryption was taking so much longer on the server when my tests had shown that a lengthy message could be encrypted in tens of milliseconds. Something was afoot.
Thirty minutes of detective work later, I discovered that problem. The good news is that my encryption algorithm wasn't guilty; it was the way I was constructing the string of encrypted characters. I was adding each encrypted character to my output string one-by-one using standard string concatenation, i.e. encryptedMessage += nextCharacter. As it turns out, doing that tens of thousands of times is a rather slow process. The technical reasons being that 1) a new string object is created on each iteration, and 2) object instantiation is an expensive operation in C#. I instantly remembered the powerful StringBuilder class I had been introduced to back in 6.831. Since building up a long string one character at a time is basically the poster child for "uses of the StringBuilder class", it sped up the process dramatically. How dramatic was the speed up? I asked myself the same question and, like a true engineer, took the time to write up a short benchmarking test to compare string concatenation and StringBuilder. Drum roll please...
WOW, I don't know if I've even seen a smoother quadratic curve made from non-fudged test data! Unfortunately it's a quadratic curve of the slowness that is string concatenation. Building a 60,000 character string using StringBuilder was three orders of magnitude faster than string concatenation...1,000x faster. Also, although it's difficult to tell from the graph, the StringBuilder curve is almost exactly linear while the string concatenation curve is clearly quadratic.
Now, a bunch of you are probably saying, "But, Matt, you said you ran tests that showed encrypting AND constructing a string of 30,000 chars took just 100ms. What gives?" Well, I ran those tests in JavaScript with a mindset of "There's no way C# could be slower than JavaScript. If it's fast in JavaScript, it'll be even faster in C#.
" Well I was wrong. Not just wrong...quadratically wrong.
So the morals of the story? 1) StringBuilder >> concatenation, 2) Never assume C is always faster, and 3) You'll always make mistakes...just make sure you learn from them.