Performance C# vs VB RRS feed

  • Question

  • Please I am not starting another debate on one language or another, but I am looking for advise.

    After many years, I have decided it's probably best to start writing code in c# rather than my preferred language of VB.

    Therefore I have started porting VB.NET routines from a class library into a C# class library.

    I completed the first couple of routines and decided to link them up to a console app to test them.

    They work and did their job, but part of the test involved volume testing so I set the limit at 1 million.  It took 42 seconds to complete. I know 42 seconds is not a lot of time for a 1 million test run, but somehow it seemed slow to me, so I created a console app and fired the same test conditions at the VB.NET class library routines.  Same machine, same work load, same routines doing the same task and the exact same logic.  It completed in just 7 seconds.

    In IT terms the difference is vast.  Two routines were tested back to back, i.e. Routine A took an input, output from routine A given to routine B, output from routine B checked to make sure its correct.

    Routine A & B are only about 25 lines of code each in C#. They perform message switching and routine and involve a lot of boolean logic to do their job correctly.  The end result, as I said is correct.

    So where could I be going wrong?

    Advise and thoughts appreciated.


    Thursday, January 31, 2019 6:22 PM

All replies

  • Hello,

    Without seeing the code there is no way to tell why one takes longer than the other.

    I've written in both languages performing large memory and/or disk operations where if there were time differences when written well milliseconds were the time differences. Usually C# was always a tad faster.

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    Thursday, January 31, 2019 8:07 PM
  • Without seeing the two code based examples you tested with, you really can't make a determination about speed  between the two. Secondly, what was the test harness you used with C# to run the test, as opposed to you running VB.NET and using a console program? 

    C# and VB.NET are managed code that generate Intermediate Language and run on the  Common Language Runtime. In some case VB.NET is faster, and in some cases, C# is faster from what I understand, which is dependent on what the code is doing from what I understand. 

    If you want speed, then you'll use C++ that is an unmanaged  coding language.

    Thursday, January 31, 2019 10:06 PM
  • Hi Haywardi,

    As far as I know, C# or VB.Net all will be compiled to IL language, I would suggest that you could compare the IL language after building them to dll (exe). 

    We could get IL information via tool named IL DASM

    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Friday, February 1, 2019 5:56 AM
  • Hi Karen,

    Totally understand your point about seeing the code, however some of the code is encrypting the data before it sends it out over the internal network to prevent eavesdropping via something like Wireshark so showing the actual code is a problem.  

    A couple of thoughts whilst acknowledging my core skill is in VB so I will inevitably write better code in VB and the C# code to anyone used to VB or c#, it still looks like VB!

    Thought 1:

    - I was surprised when coding in C# that I ended up having to convert data types all the time.  For the code to work successfully in VB I had used BYTE datatype as it gave me fewer bits to play with and when you encode a datastream TCP/IP uses byte to transmit.  Therefore it was logical to keep everything in BYTE's.  In VB this is easy as you do some maths and then plonk the result into the byte, provided it fits off you go.  However, in c# you do your maths, it always seems to return an integer value which VS wouldn't let you put into a byte unless you ended up using something like:

    A= Convert.tobyte (C*2)

    I would imaging the Convert.tobyte is taking resources and gives no benefit because if the result doesn't fit into the byte A at runtime it will crash anyway!  I get the same problem if I change C*2 to C+D where both C&D are bytes

    Therefore is there a better way of coding the maths to return a byte rather than an integer as this would avoid the need to invoke convert.tobyte?

    Though 2:

    Apart from the above oddity, the rest of the code is really just for loops coded as follows:

    foreach(char C in Token){}

    for (byte LoopCount = 0; LoopCount<TokenLength; LoopCount = Convert.ToByte(LoopCount + 3)) {}

    And both modules themselves are just 25 lines of actual code.

    Thoughts appreciated.



    Friday, February 1, 2019 8:22 AM
  • Understand your comment regarding wanting to see the actual code, but take a look at my reply to Karen as I do give some examples.

    OMG!  There must be a good reason, but why do an intermediate...  That makes it a interpretative language which is crap for performance!  Grrrr.  However, if both VB and C# are interpretative then it doesn't explain the problem....

    Why not c++, good question.  My only answer is that I want to write a mobile app using Xamarin and that only seems to support c#!

    However, can I write my mobile phone app in C# and it interface into a C++ library?  Now that would be cool and give me everything I am looking for?



    Friday, February 1, 2019 8:30 AM
  • OMG!  There must be a good reason, but why do an intermediate...  That makes it a interpretative language which is crap for performance!  Grrrr.  However, if both VB and C# are interpretative then it doesn't explain the problem....


    The IL is used by the .NET Framework to generate machine-independent code as the output of compilation of the source code written in any .NET programming language.



    CLI languages are computer programming languages that are used to produce libraries and programs that conform to the Common Language Infrastructure (CLI) specifications. With some notable exceptions, most CLI languages compile entirely to the Common Intermediate Language (CIL), an intermediate language that can be executed using an implementation of CLI such as the Common Language Runtime (CLR, a part of the Microsoft .NET Framework and .NET Core), Mono, or Portable.NET.



    To put it very simply, managed code is just that: code whose execution is managed by a runtime. In this case, the runtime in question is called the Common Language Runtime or CLR, regardless of the implementation (Mono or .NET Framework or .NET Core). CLR is in charge of taking the managed code, compiling it into machine code and then executing it. On top of that, runtime provides several important services such as automatic memory management, security boundaries, type safety etc.


    Why not c++, good question.  My only answer is that I want to write a mobile app using Xamarin and that only seems to support c#!


    Create native C++ apps for iOS, Android, and Windows devices with Visual Studio.


    Friday, February 1, 2019 10:54 AM
  • > OMG!  There must be a good reason, but why do an intermetiate...  That makes it
    > a interpretative language which is crap performance!

    Not so.  C# was created in response to Java, which works in exactly the same way.  The code is compiled to an intermediate language, then when the program is loaded in memory, the IL is "just-in-time" compiled to assembly language before being executed.  In comparison to a straight-to-assembly compilation like native C++, the performance difference is quite small.  The JIT compilation has just as many optimizations as a native C++ compiler, but by putting it in the runtime, those optimizations are shared by ALL of the .NET languages: C#, VB, F#, IronPython, IronRuby, etc.

    This is different from an interpreted language like Python, which is also compiled to an intermediate language, but at runtime the inner loop interprets the IL code step by step.

    Tim Roberts | Driver MVP Emeritus | Providenza &amp; Boekelheide, Inc.

    Friday, February 1, 2019 11:02 PM
  • Thank you everybody for the comments regarding compiling to a IL.  OK, I can understand it makes the run time machine independent.  I can also understand the IL can be interpreted fast, but never as fast as machine code.  But hay ho, the powers that be decided so that's the way it is!

    To go back to my question, I still think it's linked to the extensive use of Convert.tobyte that I have to use every time I place a variable in a byte datatype, is there a way of programming such that you can default the datatype for calculations or something like that?

    Thanks in advance.



    Saturday, February 2, 2019 3:33 PM
  • A few comments:

    No, the IL is not interpreted. When you launch the executable, the Just-In-Time (JIT) compiler takes over and compiles the IL into machine code. Then your program executes from the machine code. This compilation is done only once the first time that the method is invoked. And yes, it will consume a small amount of time. If you want to avoid this minuscule effect, there is a tool called NGEN that allows you to compile into machine code and save on disk the compiled machine code.

    About the "Convert.ToByte": I recommend using a cast instead, e.g.:

    A = (byte)(C*2);

    This should in theory be faster than the method call to Convert.ToByte().

    And finally, about your not wanting to show your code because it performs encryption: As any cryptography expert will quickly point out, security by obscurity is a really bad idea. It will eventually be broken, most likely sooner than later. Either use a known and proven encryption method (there are many available in the .Net libraries) or, if you absolutely need to create your own, then you should publish it in a very public place and allow it to be criticized so that its flaws are pointed out and can be polished away.

    Sunday, February 3, 2019 2:04 PM
  • Alberto,

    Thank you for taking the time to wrote such a considered reply.

    I now understand the premise for the use of the IL.  It is much more than an interpreted language and I accept that point.

    Thank you for the advise on using (byte)(c*2) I will use it and re-run to see how it improves the processing speed.

    Your point about encryption is well made and accepted.  I am a bit old school in this respect and understand there is a trade off between public/peer review and obscurity.  But I am not attempting to write a replacement for SSL, just secure some data away from prying eyes and by opening up public review creates its own problem when it comes to opening up attack vectors. 

    You also correctly reason that every cypher eventuality gets broken so using standard ones gives greater focus to breaking theses as the reward is big (enormous even).  My little routines, probably not worth the effort :-)

    Care to test my theory? I will happily post an encrypted string, I will even tell you the type of data encrypted (lets say a UK telephone number)


    Monday, February 4, 2019 4:05 PM
  • Care to test my theory? I will happily post an encrypted string, I will even tell you the type of data encrypted (lets say a UK telephone number)

    No, that would not be enough. The way that a code breaker would operate is by installing a network sniffer and capturing lots and lots of packets. They then use clever algorithms to examine them for things such as recurring patterns that can give them some clues. They can also guess some of the encrypted data, for instance, if they are telephone numbers they can guess some of the numbers by finding out who are the people that you deal with. This can help them in inferring the encrypting algorithm. The process is extremely complex, and there are not that many experts who can do it. But those who are trained on it are sometimes extremely clever. Of course, you can argue that given the limited number of experts and the small importance of your program, no one will ever bother. That's a valid point.

    As an additional risk, bear in mind that the program that you use on both ends for encrypting/decrypting can be easily decompiled if someone manages to get their hands on the executable, which becomes more likely the more computers are running it. Contrary to the crypto-analysis, which is difficult, decompilation is easy to do so the risk on this area might be bigger than the other one.

    Monday, February 4, 2019 6:20 PM
  • Hi Iain,

    We don't really care about the encryption. That's just for the data. Unless you're using a  "roll-your-own" encryption routine, showing us the 25 lines of code in VB and C# shouldn't matter to you, from a proprietary standpoint. Is all this Byte conversion part of a "roll-your-own" encryption routine?

    ~~Bonnie DeWitt [C# MVP]

    Tuesday, February 5, 2019 2:10 AM