3

During tests I found out that my method takes up to 70% less time when I use implicit conversions than explicit. Why is implicit so much faster? Would you consider to use implicit in this case even if it's against any kind of coding style?

Note: the variable val contains a hex decimal string and there is no case it does not.

Implicit (the whole method takes up to 3 seconds):

"&H" & val >= &H100000

Explicit (the whole method takes up to 10 seconds):

Int.Parse(val, System.Globalization.NumberStyles.HexNumber)  >= &H100000

Note: I've also tried Int.TryParse but implicit is still a LOT faster.

J...
  • 30,968
  • 6
  • 66
  • 143
user7436839
  • 57
  • 2
  • 1
    What if you use `CInt("&H" & val)` instead of `Int.Parse`... the latter is a rather more flexible (and therefore expensive, I would guess) method since it has to consider all of the possible options that the `NumberStyle` encapsulates. Put another way, `Int.Parse` is not an explicit conversion - it's a complex parsing method that can do a lot more. The direct comparison should be with `CInt`, which is the explicit conversion method. – J... Feb 01 '17 at 23:35
  • I'm guessing that this question is specifically for VB since you can't do bitwise operations on strings in C#, nor does that literal syntax exist. – Abion47 Feb 01 '17 at 23:53
  • Cint() seems to cause maginal performance loss (3.1 seconds). Still wonder why Int.Parse or Int.TryParse is SO much slower... – user7436839 Feb 02 '17 at 00:06
  • @Abion47 `&` is used for string concatenation in VB instead of `+` - the performance implications, I would guess, are identical. – J... Feb 02 '17 at 00:10
  • @J... Even with that in mind, the first line of code still makes absolutely no sense in a C# context. In C#, hexadecimal literals look like `0x100`, but they are treated as integers, not strings. You don't concatenate them, you add them. And using `int.Parse`on them would make absolutely no sense because A] they aren't strings, and B] they are already integers. So in C#, I would say that there are no performance implications here at all because either it would not compile or it would run much faster due to there being no need to parse a string in the first place. – Abion47 Feb 02 '17 at 00:16
  • The first snippet creates a string, which isn't really checking what you think it is when you're using `>=`. Checking two strings like that (which the second probably becomes) is not the same as checking two actual numbers. – Visual Vincent Feb 02 '17 at 00:17
  • `In C#, hexadecimal literals look like 0x100, but they are treated as integers, not strings.` - VB.NET's hexadecimal numbers are not treated as strings either, but if you do `"&H" & val` you'll create a string since the ampersand (`&`) in-between `"&H"` and `val` is a string concatenation operator. – Visual Vincent Feb 02 '17 at 00:19
  • @Abion47 But here `val` is a string with some content like `"FF755"`, etc. The first snippet is identical to `Convert.ToInt32("0x" + val, 16) >= 0x100000`... the only difference is that VB.NET (regrettably) allows you to make an implicit conversion when `Option Strict` is turned off. `Convert.ToInt32` is semantically equivalent to `CInt` in VB (although both are valid) and these are demonstrably equally performant. The question really is about why `Int.Parse` is much slower than `Convert.ToInt32`. – J... Feb 02 '17 at 00:47
  • 1
    Possible duplicate of [Whats the main difference between int.Parse() and Convert.ToInt32](http://stackoverflow.com/questions/199470/whats-the-main-difference-between-int-parse-and-convert-toint32) – J... Feb 02 '17 at 00:52
  • actually, also possibly : http://stackoverflow.com/q/566147/327083 – J... Feb 02 '17 at 00:55
  • So `CInt` is actually an operator - not the same as `Convert.ToInt32`...and faster. Seems VB.NET has better type conversion intrinsics than C# since the language was originally designed to be so type lazy and has to handle these types of conversions implicitly so often - especially with legacy code and `Option Strict` nonbelievers... – J... Feb 02 '17 at 00:59
  • @J... Reading your linked possible duplicate, I don't think that the first snippet is identical to a `Convert.ToInt32` call, but is merely syntactically similar. I'm not all that familiar with VB, but I suspect that what is happening under the hood of the first snippet is actually far different than what "equivalent" C# would look like. Furthermore, `Convert.ToInt32` *calls* `Int32.Parse` when given a string parameter, so it would make no sense as to why the former would be significantly faster. I'm still of the opinion that the C# tag should be removed. – Abion47 Feb 02 '17 at 01:33
  • @Abion47 Yeah, I'm tending to agree at this point also. I assumed that `CInt` (VB) was just sugar for `Convert` but it's not - it's a VB intrinsic that handles implicit type conversions that are simply not allowed in C# (and is surprisingly more performant, although not really *equivalent*). The second link I posted above has more info and is probably the better dupe. – J... Feb 02 '17 at 01:36
  • 1
    Possible duplicate of [\*Subtle\* Differences between VB functions and Convert.To\* functions?](http://stackoverflow.com/questions/566147/subtle-differences-between-vb-functions-and-convert-to-functions) – Abion47 Feb 02 '17 at 01:39

0 Answers0