Take the 2-minute tour ×

Which one is faster, powerfull and reliable. And why ?

share|improve this question

6 Answers 6

up vote 9 down vote accepted

Go read this ("Performance Profiling Parse vs. TryParse vs. ConvertTo") for much add'l info.

If you are unsure if the string is parsable, then int.TryParse() will be MUCH faster than either of the others and catching the exceptions.

share|improve this answer

Both int.Parse and Convert.Int32 internally call int.TryParse, so performance differences between them should be trivial. TryParse is the most versatile in that it allows you to decide whether or not to throw an exception, but otherwise there is no difference between these methods.

share|improve this answer
Actually, if you take a look in Reflector, int.Parse calls Number.ParseInt32 internally...it never calls int.TryParse. –  Justin Niessner May 27 '10 at 15:45
I was thinking the same thing. I was about to go open up some source code, but I'll take your info as confirmation. –  Jaxidian May 27 '10 at 15:46

Convert.ToInt32(string) calls Int32.Parse(string).

However, if you use Int32.Parse (or the equivalent int.Parse), you can specify globalization and formatting used when parsing.

Int.Parse will be faster since it doesn't do a try/catch.

Int.TryParse is more reliable and won't throw an error if you don't pass it a non-convertible value.

share|improve this answer
Actually, if you take a look in Reflector, int.Parse calls Number.ParseInt32 internally...it never calls int.TryParse –  Justin Niessner May 27 '10 at 15:49
@Ed: Who says TryParse has to be implemented in terms of Parse, and not the other way around? –  BlueRaja - Danny Pflughoeft May 27 '10 at 15:49
This somewhat contradicts what is written in the benchmark referenced by Jaxidian. int.Parse won't be faster according to that. –  Dirk Vollmar - 0xA3 May 27 '10 at 15:51
@Ed There is no try/catch in TryParse either. If you look at the internal code being called, where Parse would throw an Exception TryParse simply returns false. Throwing an Exception adds more overhead, thus slowing things down. –  Justin Niessner May 27 '10 at 15:53
doh...you're right –  Ed B May 27 '10 at 15:57

I personally use


if I have a string as a source and


if I have a valueType (double, decimal) as a source, because otherwise I had to cast it to strings and deal with the local culture.

share|improve this answer
I use int.Parse if I want an exception thrown on a string that I'm parsing (i.e. an API that expects a page number or something as a querystring parameter). I use int.TryParse on a string that I'm parsing if I want to handle it right then and there. I use Convert.ToInt32 if it's not a string (whether it's a decimal, an int boxed in an object, or whatever). So I'm on page with you. :-) –  Jaxidian May 27 '10 at 15:59

Convert.Int32() calls Int32.Parse() with an extra check for null, so Int32.Parse() might be a tad faster. which is why Convert.Int32() will be faster (it catches the null before Int32.Parse() has to deal with it).

Int32.Parse() calls Number.ParseInt32() internally which throws Exceptions when a number can't be parsed.

Int32.TryParse() calls Number.TryParseInt32() internally which has similar code to Number.ParseInt32() but instead of throwing Exceptions it simply returns false...which introduces less overhead.

Considering all those variables, my guess would be that Int32.TryParse() will give you the fastest results for non-null values. If there's a chance the majority of the calls could contain nulls, I would say Convert.Int32() would perform better.

...all that brought to you by the power of .NET Reflector.

share|improve this answer
+1, but regarding "so Int32.Parse() might be a tad faster": I guess you won't be able to measure the null-check. In fact it will be slower if your input is null according to blogs.msdn.com/b/ianhu/archive/2005/12/19/505702.aspx: "The difference is, as we guessed, in the exception handling code. That is why Convert was faster then Parse as Convert handles the null string in the bad data set without throwing an exception." –  Dirk Vollmar - 0xA3 May 27 '10 at 15:52
@0xA3 Updated my answer to reflect the comment. Thanks for the catch (and reference). –  Justin Niessner May 27 '10 at 15:55

I find that the answer depends on the context.

If I'm converting (for example) a DataRow to an object, I'll have lots of Convert.ToXXX calls, so I would use Convert.ToInt32 because that is consistent with the other statements around that conversion.

In other situations, if I want to throw an exception when the string does not parse (fail-fast) I'll use int.Parse, because that throws the exception for me, and int.TryParse tends to generate uglier code (I've never been a fan of out parameters)

And if I just want to specify some default value if the string does not parse, I'll use int.TryParse, because otherwise, I'll have to handle the exception myself, and that is both expensive and ugly.

However, unless you are calling the parsing site billions of times, I would be surprised to see a discernible time difference between any of the three formats, so I would prefer a more readable piece of code, over a marginally faster variant.

share|improve this answer

Your Answer


