Performance testing of Dictionary - List - Hashtable

Still working with high-volume realtime datafeeds, I'm struggling to understand where the bottleneck in my code is. It's not with the database, it's not with the network - it's somewhere in the code. Now that doesn't help a lot.

So I decided to have a look at the different data structures that could be usable for my needs. Right now I'm using a List to keep track of my orders, and each time I get a new order, I check that list for the given ID.

So I'm starting to wonder, maybe there is a performance issue with the List data structure. So I made a small test with the following code:

static void TestList()

{

var watch = new Stopwatch();

var theList = new List<int>();

watch.Start();

//Fill it

for (int i = 0; i <>

{

theList.Add(i);

}

watch.Stop();

Console.WriteLine("Avg add time for List: {0}", (watch.Elapsed.TotalMilliseconds / noOfIterations));

watch.Reset();

watch.Start();

//Test containsKey

for (int j = 0; j <>

{

theList.Contains(j);

}

watch.Stop();

Console.WriteLine("Avg Contains lookup time for List: {0}", (watch.Elapsed.TotalMilliseconds / noOfIterations));

}

I created similar test code for Dictionary and HashSet. In all of the tests I used a loop where the given key always existed in the data structure. I used Add instead of Insert, because of tests I've seen online show that this is much faster. For example, this one.

First run, I used 1,000 for the noOfIterations variable and ran it three times.

The horizontal scale here is in milliseconds, so things are reasonably fast. A value of 0.2 gives you a possible 200 adds per second. As you probably can see without checking the numbers, dictionary is faster. List is slower for lookup, but HashSet suprises a little with the slow add function. So what happens when we go to 100,000 items?

OK, List is a lot slower for lookup still. Add seems to compare ok though. Let's see how it compares if we remove the lookup-time from the chart:

Now that's a result! Turns out List is your winner if fast adding is all you care about. If you want to look up your values later though, dictionary is your winner. Hope this will save some time for other developers in the same situation. Also feel free to comment if you find different results, or a problem with my test!

Resources: softscenario.blogspot.com

Comparing CI build tools: Cruise Control and Hudson

	Hudson		Cruise Control
1	Open Source	1	Open Source
2	Easy installation: Just java -jar Hudson.war, or deploy it in a servlet container. No additional install, no database.	2.	It also gives us very easy installation. Just unzip the downloaded zip file. That’s it. It is actually using an internal Jetty server. No Database, no install here also.
3	Easy configuration: Hudson can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There’s no need to tweak XML manually anymore, although if you’d like to do so, you can do that, too.	3.	Big difference comes here. The GUI providing by Cruise control for configuration is not at all good. It just displays the config.xml file. Its no way near to Hudson for Configuration GUI part. If you want to configure Cruise Control then you must study about the structure of the Config.xml first.
4	Change set support: Hudson can generate a list of changes made into the build from CVS/Subversion. This is also done in a fairly efficient fashion, to reduce the load of the repository.	4.	Cruise control also show the list of files which are changes at this check-in process.
5	Permanent links: Hudson gives you clean readable URLs for most of its pages, including some permanent links link “latest build”/”latest successful build”, so that they can be easily linked from elsewhere.	5.	Uhm… Cruise control is not giving this. It gives a link with some log code number attached with it. Its looking horrible and cant be easily likable.
6	RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.	6.	It also gives RSS and email functionality. Don’t know about IM support. If we need to change the Email structure then either we have to change XSL or CSS file which we are using in the email config.
7	After-the-fact tagging: Builds can be tagged long after builds are completed	7.	N.A.
8	Detect new failing tests while build	8	Failing tests will show in the dashboard. But no separation between new and old.
9	Notify when first test in build fails	9	No such type of notification.
10	JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.	10	It is showing all the unit test results but not as good as Hudson does. There is no detailed information like when it started breaking, History etc. and no graph for unit results too.
11	Distributed builds: Hudson can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers’ desks.	11.	The build distribution is done through the maven install goal. Its
12	File fingerprinting: Hudson can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Hudson, and is ideal for projects to track dependency.	12.	No idea.
13	Plugin Support: Hudson can be extended via 3rd party plug-ins. You can write plug-ins to make Hudson support tools/processes that your team uses.	13.	Plug-ins are there in Cruise control also.
14	Dash board: Hudson has an attractive dashboard with Colorful as well as meaningful icons. We can separate this building projects into subgroups also. It will also shows building projects. Well designed Ajax pages.	14.	It gives an attractive Dash board. It displays all the necessary information which we need to know. We can directly build from there also. Viewing/ downloading the log file is also allowed from this Interface.
15	Local Copy of projects: Handled by Hudson itself. No need to do by the user.	15.	Maintaining a local copy with the exact SVN data makes us more uncomfortable. The user has to copy the Project into the local folder with SVN data.
16	Auto copy of SVN updates: No need to provide any other code to copy the project from SVN to the local compiling folder.	16.	Its not copying the data from the SVN directly. We need to write (In our case we wrote an ANT build file to download the latest copy of Project from SVN) something separate.
17	Running In background: If the server where we deployed the war is running then its okay for Hudson.	17.	If we want to run it without console then we need to make it a separate ‘WINDOWS Service’ using any third party tool.
18	We can deploy the war file in any of the server we wanted.	18.	Jetty server is using internally.
19	User authorization schemes. more configurable.	19.	User authentication is there but no schemes at all.
20	Very Active mailing list.	20.	From a long period people are using this. So it gives so many search results. But its mailing list is not that much active when compared with Hudson.

Conclusion:

In my opinion Hudson much more better than Cruise Control. The time we will take to start to use Cruise control will be high when we compared with Hudson. The GUI which makes all the Configurations very very easy. The Ajax support makes the configuration more “Error Free”. Though Cruise control is using by a lot of people, when we looked into the features, mailing list, the fastness and support from Developers I think Hudson will be a good option.

Resources: lijinjoseji