Posted on 2/9/2010 1:09:54 AM by Justin Etheredge
It pretty much goes without saying that if you are building a public facing website these days you are probably using a ridiculous amount of JavaScript. And it is also likely that most of the JavaScript is in the form of libraries that you didn't write and you don't maintain. But even if you aren't maintaining those libraries, you are still responsible for pushing them all down to your users. And so you can get into the situation where you have either hundreds of kilobytes of JavaScript or you just end up with a ton of tiny script files. Both of these can really put a damper on the amount of time that your site initially loads for your user.
Fortunately for us there are several solutions to the problem of slow loading JavaScript. One is to try and load most of your libraries from content delivery networks (CDN) provided by companies like Google and Microsoft. A second is to employ a CDN of your own like Amazon's CloudFront. But no matter what you are doing to speed up your the delivery of your JavaScript, it is absolutely imperative that you do three things:
- Combine your JavaScript files: Concatenate all of your JavaScript files into a single file so that the browser only has to make one request to download your scripts.
- Minify your JavaScript files: Perform some optimizations on your JavaScript to remove whitespace, shorten variable names, and in some instances even perform some static analysis to optimize statements or remove unused code.
- Compress your JavaScript: Enabled gzip compression so that users that have browsers which support compression will receive a smaller file.
Now this may sound like a lot of work, but thankfully people like my friend Dave Ward have already solved the problem of easily combining and minifying our JavaScript files in a pretty easy way. However, I was looking at one of my favorite JavaScript libraries, SyntaxHighlighter, and I was thinking that it was just an absolutely huge amount of files that you had to import in order to use it. SyntaxHighlighter has hosted versions of its files, and so wouldn't it be cool if I could just pull those hosted versions, along with my other javascript and then combine, minify, and then just push all of that up to my CDN?
Continue reading the rest of this post...
Posted on 2/8/2010 11:12:56 AM by Justin Etheredge
In .NET 4.0 there is a new namespace on the block, and it is called System.Collections.Concurrent. In this namespace you will find a pretty decent number of goodies that will help you to more easily write application which can leverage multiple threads without having to resort to manual locking. We looked previously at the ConcurrentBag, ConcurrentStack, and ConcurrentQueue. Well, I have two more goodies to show off, and those are the BlockingCollection class and the IProducerConsumerCollection interface.
In order to get this party started, let me explain exactly what the IProducerConsumerCollection is and why we would want to use it. The IProducerConsumerCollection interface is pretty simply and really exposes only two methods that we care about: TryAdd and TryTake. You see, IProducerConsumerCollection is designed for multi-threaded producer/consumer scenarios, which means situations where we have multiple threads producing pieces of data (producers), and then multiple threads that are trying to consume those pieces of data (consumers). So, IProducerConsumer just signifies that the implementing type supports thread-safe adding and removing of data. (In .NET 4.0, the types that will support this interface are the ones that we already looked at: ConcurrentStack, ConcurrentQueue, and ConcurrentBag)
Continue reading the rest of this post...
Posted on 2/4/2010 9:28:50 AM by Justin Etheredge
In .NET 4.0 we have several new collection types that have been introduced inside of the System.Collections.Concurrent namespace. The one that we are here to talk about today is the ConcurrentQueue. The ConcurrentQueue is a lock-free thread-safe implementation of the standard queue data structure. A queue is a data structure that has FIFO (First In First Out) semantics, and it has two main operations, enque and dequeue. Enque puts a new item at the end of the queue, and dequeue takes the item off the end of the queue.
You can think about it like a line at a store:
Items go in at the end, and come out of the front. So the first person in the line is the first person out of the line. Like we said, FIFO! In order for us to interact with the ConcurrentQueue, we have two main methods. These are "Enqueue" and "TryDequeue".
Continue reading the rest of this post...
Posted on 2/1/2010 9:52:28 AM by Justin Etheredge
In .NET 4.0 we have several new collection types that have been introduced inside of the System.Collections.Concurrent namespace. The one that we are here to talk about today is the ConcurrentStack. The ConcurrentStack is a lock-free thread-safe implementation of the standard stack data structure. (As a side note, when I say "lock-free", I mean that they don't leverage traditional locks using the "lock" keyword or using Monitors. They do however use the System.Threading.Interlocked class to perform compare and swap operations.)
A stack is a data structure that performs operations in LIFO (Last In First Out) order, and it has two main operations, push and pop. Push puts a new item on the top of the stack, and Pop takes the item on the top of the stack and removes it.
You can think about it like a stack of plates:
The last item put on the stack, is the first item that is popped off the stack. As we said, Last In First Out. In the ConcurrentStack implementation we have two main methods that we will use when interacting with it. First is the "Push" method and second is the "TryPop" method.
Continue reading the rest of this post...
Posted on 1/27/2010 9:40:52 AM by Justin Etheredge
Inside of .NET 4.0 there are numerous new namespaces, but the one that we are here to talk about today is called System.Collections.Concurrent. This namespace contains a handful of types which implement different types of thread-safe collections. The thread-safe collection type that we are going to take a look at today is the ConcurrentBag<T>.
The ConcurrentBag<T> is one of the most simple concurrent types which has been introduced. It is a typical bag data structure (also known as a multiset), meaning that it is an unordered collection of items that allows duplicates. It is called a bag because if you were to draw a diagram of the data structure, it would look something like this:
Just a jumble of items, with no order at all. It has three important methods, which are "Add", "TryTake", and "TryPeek". Add works exactly as you would expect, you simply instantiate a ConcurrentBag instance and then call Add in order to put items into it:
Continue reading the rest of this post...