Revelations

I have been using a trial version of ReSharper for my DotSVN project and I should say that I just got hooked to it. I would not have made this much progress without it and that leaves me wondering what I would do once the trial expires!!

A tool with this ease of use is needed to improve the design and code without any hesitation to refactor.
ReSharper's code navigation capabilities are also extra ordinary. You can read more about it here.

I have also used dotTrace to fix a nasty performance issue.

Overall I am very satisfied with the product.

Posted by George Chiramattel at 12:28 PM | Permalink | Comments (0) | TrackBacks (1)

I would like to write a series of posts describing the various performance issues I faced while implementing DotSVN.

In this post I discuss the performance penalty of using DateTime.Parse().

During my testing, I found that DotSVN was running quite slow. I used a trial version of 'JetBrains dotTrace 3.0' to analyze the problem. The following is a screen-shot of the dotTrace session.


As you can see, 26% of the time is spend on the method call 'System.DateTime.Parse()'. This was unacceptable. After some investigation I found that the performance of the DateTime Parse method can be improved if we give some clue on formatting of the date string. This can be achieved using the ParseExact() method.

note: I have updated the code to re-use the CultureInfo class.
AlexKucherenko - Thanks for the comment.

private static readonly CultureInfo en_us_Culture = new CultureInfo("en-US");

// Parse in the format [2007-09-06T10:20:26.689093Z]
private static readonly string dateTimeFormat = "yyyy-MM-ddTHH:mm:ss.FFFFFFFZ";

public static DateTime parseDate(String dateString)
{
	DateTime parsedDate;

	bool parseResult = DateTime.TryParseExact(dateString, dateTimeFormat, 
							en_us_Culture, 
							DateTimeStyles.AdjustToUniversal, out parsedDate);
	if(!parseResult)
	{
		SVNErrorMessage err = SVNErrorMessage.create(SVNErrorCode.BAD_DATE);
		SVNErrorManager.error(err);    
	}
	return parsedDate;
}

The performance gain is quite obvious with the following figure, which shows the dotTrace session after applying the above fix.


As you can see, DateTime.Parse() is no longer a hot Spot. This also shows the power of dotTrace, and how it helped to quickly narrow down the issue.

Posted by George Chiramattel at 12:40 PM | Permalink | Comments (2) | TrackBacks (1)

I wanted to discuss a problem that I faced while implementing the repository layer of DotSVN.
When I tried to use the System.IO.Compression.DeflateStream to decompress the repository, I get the exception 'System.IO.InvalidDataException' : "Block length does not match with its complement."

I Googled around an found this article that explains the problem. The feedback from Microsoft on how to fix this issue is as follows:

...skipping past the first two bytes solved the problem. Those bytes are part of the zlib specification (RFC 1950), not the deflate specification (RFC 1951). Those bytes contain information about the compression method and flags.

The zlib and deflate formats are related; the compressed data part of zlib-formatted data may be stored in the deflate format. In particular, if the compression method in the zlib header is set to 8, then the compressed data is stored in the deflate format. This is true in the case of the stream you submitted, which was taken from a pdf file.

Our DeflateStream, on the other hand, represents the deflate specification (RFC 1951) but not RFC 1950. So your workaround of skipping past the first 2 bytes to get to the deflate data will definitely work.

So the actual code would look like the following:

// create a file stream, as before
FileStream fs = new FileStream("file", FileMode.Open);

// skip first two bytes
fs.ReadByte();
fs.ReadByte();

// now create the deflate stream and proceed as usual
DeflateStream l_Stream = new DeflateStream(fs, CompressionMode.Decompress);

Posted by George Chiramattel at 3:55 AM | Permalink | Comments (0) | TrackBacks (1)

I have been working (along with my sister and cousin) on an XMPP based IM client. This is fully implemented in DotNet. The current version (1.0.1) can connect to Google Talk. The project is hosted here. 

You can get the latest code from the following SVN url:
http://chatapp.googlecode.com/svn/trunk/

Here are some screen shots of the application.

 

And the Chat Window

The 'About Box' describes the different components that we are using.

 I would appreciate your valuable comments - please post them here.

Posted by George Chiramattel at 1:45 AM | Permalink | Comments (2) | TrackBacks (1)

In the article titled 'The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software', Herb Sutter explains the importance of improving our skills on writing concurrent programs - ie if we need to gain performance gains form all the multi-core CPUs that are coming out lately.

In this light, I have collected a series of articles that discuss this matter in detail.

• An Introduction to Programming with C# Threads
• Threading in C#
• CLR Inside out: Using concurrency for scalability [MSDM Mag Sep 2006]
• What Every Dev Must Know About Multithreaded Apps [MSDN Mag Aug 2005]
• Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps [MSDN Mag April 2006]
• WinForms UI Thread Invokes: An In-Depth Review of Invoke/BeginInvoke/InvokeRequred
  

Hope this helps.

technorati tags:Threading, Concurrency, CSharp

Posted by George Chiramattel at 12:30 PM | Permalink | Comments (1)

Community Server :: Forums (A .NET Open source discussion engine.), Community Server :: Blogs (A .NET Open source blogging engine) and Community Server :: Gallery (A .NET Open source photo gallery) all rolled up into one package called Community Server 1.0.
According to Rob Howard, they have started work on version 1.1 with the following theme.

Performance - we intend to run both www.asp.net/forums and blogs.msdn.com on Community Server. Today these sites serve millions of users on the same 2 web servers and single database server. We've introduced new architecture into Community Server and we expect performance and scale to be better overall, but we know we'll identify some new issues with these high traffic sites.
Simplification - We want to focus on simplifying the platform. We are going to introduce more wizard as well making the administration UI even more user friendly.
Quality - A big goal for Community Server was to release a product that was of very, very high quality. We are shipping with defects - actually about 50 that we know about - but most are minor and have acceptable workarounds. We fixed over 900 bugs (that we tracked). Our goal for 1.1 is to make the platform even better than 1.1

You can get it here.
Go Ahead and have fun!

Posted by George Chiramattel at 7:43 PM | Permalink | Comments (0)

Wile developing MFC based applications, I used a lot of ASSERT statements. But when developing C# applications, I see that very few people are using this.

For me using ASSERT macros was a way of enforcing 'Design by Contract'. May be we should have a better mechanism in C#.

I have a few ideas on how to do this with .Net attributes. I will write bout this shortly.

Posted by George Chiramattel at 1:52 PM | Permalink | Comments (1)