dcsimg
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 23

Thread: vb.net ... why bother?

  1. #1
    Join Date
    Aug 2010
    Posts
    47

    Question vb.net ... why bother?

    I have spent the last 4 months converting my project from VB6 to vb.net and expect it to take almost to the end of 2014 to complete the conversion.

    Then I may have to convert the parts written in C++ and asm to run on the latest version of Visual C++

    At which point, it will run at about half the speed of the vb6 version. So what took 100 hours of computation may well take 200 hours.

    I have done this because all the propaganda tells me that I should. And because I am concerned that at some point in the future Microsoft will abandon vb6

    But, I notice that right now on this forum there are 174 people looking at vb6 and only 55 looking at vb.net. Other forums show similar viewing patterns - far more people looking at a deceased product than the new exciting future ...

    Am I wasting a year of my life?

  2. #2
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,038

    Re: vb.net ... why bother?

    Am I wasting a year of my life?
    Well it depends upon the definition of 'wasting'. Think of the fun you're having doing the conversion.
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++17 Compiler: Microsoft VS2019 (16.5.2)

  3. #3
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,248

    Re: vb.net ... why bother?

    The question is.. how many years have you already wasted?

  4. #4
    Join Date
    Aug 2013
    Posts
    55

    Re: vb.net ... why bother?

    Quote Originally Posted by wavering View Post
    Am I wasting a year of my life?
    Yours seems to be quite a common problem because Microsoft even has a resource center dedicated to upgrading legacy VB6 code. There are some tools available to ease the pain. Some are free, at least to a certain extent,

    http://msdn.microsoft.com/en-us/ms788231.aspx

    Although the proposition may seem rediculous today I can predict with 100% certainity that at some point in the future also VB.NET will be dropped for something new and fancy. And in fact since Mr. Gates has left the building the chance this will happen sooner rather than later has increased dramatically. Your porting effort will have been wasted and you will be back on square one once again.

    The lesson I think is to avoid getting stuck with company specific technologies in the first place. For your current VB6 code it's probably the right path to convert but for new projects I would recommend a more "future-proof" approach. Instead of jumping onto some company bandwaggon promoting the fad of the day, look for more open alternatives and upgrade continously as the technologies evolve not to get stuck in a time-capsule. It may be a little more work along the way but it usually pays off big time in the end.
    Last edited by zizz; May 30th, 2014 at 05:49 PM.

  5. #5
    Join Date
    Aug 2014
    Posts
    6

    Re: vb.net ... why bother?

    Quote Originally Posted by wavering View Post
    At which point, it will run at about half the speed of the vb6 version. So what took 100 hours of computation may well take 200 hours.
    That isn't untypical. But with additional work you may be able to get closer to the VB6 speed. Remember VB6 uses the C++ compiler and so can be difficult to match in speed.

    I have done this because all the propaganda tells me that I should. And because I am concerned that at some point in the future Microsoft will abandon vb6
    Microsoft have stated that the VB6 programming language will be supported until 'at least' 2024. What happens then ? Who knows ? But then, who knows what will happen to VBdotNet too ?

    My guess is that VB6 will continue as long as the Windows desktop (as we know it) will. And VBdotNet may also continue as long.

    Whether it is worth spending time migrating is difficult to know, if you do so there is a risk you may need to migrate again.
    My personal view (with what is known at present) is that unless you plan to change the application to a web or mobile app it is best not to migrate. But do keep up with what Microsoft decide to do to Visual Basic programming and be prepared to act accordingly.

  6. #6
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: vb.net ... why bother?

    if you changed the VB6 to VB.net with the explicit purpose of making it go faster.
    Then you shouldn't have started at all.

    If you did so with another purpose in mind, then yes, you'll loose some performance and gain whatever it is you started the migration for. Is this a waste ? I would guess not, you obviously started this with the other purpose as an objective.


    .net in any flavour (basic, C#, J#, C++) makes your code run slower. you can drop all the BS and attempts at claims otherwise, but this is a given fact. However, what you gain is an easier UI development and integration path. Depending on what you do, you will also get a load of headaches dealing with the garbage collector.
    If performance is less of an issue to you, and you want safer/easier UI/integration development, then .net (any language) is the thing for you.


    if performance is your main goal. you shouldn't have used VB in the first place. VB6 was never really good at that either.
    develop your time critical code in C, C++, or some other language that has a decent compilation and optimisation to native code.
    You can still develop your non-critical UI code in .net if you like or decide to write it all in C, C++ or whatever.

  7. #7
    Join Date
    Aug 2010
    Posts
    47

    Re: vb.net ... why bother?

    The project is written in VB6. All time critical routines are in VC++ 6.0 (written in what is really C and ASM - the latter for bit handling, of which I do a lot)

    I am migrating because VB6 is being phased out and I cannot install the IDE on a modern Win 8 laptop (I am told it can be done but I have not managed to do it). I am also concerned that in due course ie post 2024, MS will stop VB6 programs being run

    If anybody in the UK can install VB6 and VC++ 6.0 on my Win 8 laptop, I will gladly pay you handsomely for the service! I operate between Manchester - London - Norwich triangle so I will come to you.

    Right now I am having to use XP which is no longer being maintained by Microsoft so I am in a catch 22 situation
    MOPEKS - a freeware program that generates programs that use each other to solve problems. Is this the correct route to a genuinely intelligent machine?

  8. #8
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: vb.net ... why bother?

    ideally...
    - move/change all of your non UI related code to C/C++.
    - avoid the ASM, As I outlined before, unless you have big/complex/special purpose ASM routines, then you won't gain anything, and you may very well loose performance by doing what you do now. Without seeing the actual asm routines it's hard to be concrete here, but as a rough guide, any routine less than 10 or so ASM instructions (excluding stack frame setup/parameter handling/result returning) typically isn't worth it. Even bigger once often aren't. This BIG thing to remember here is that typically speaking your compiler is a lot better at writing optimal code from a wel written algorithm and you are. Programmers that know how to make ASM truely shine are extremely rare.
    - define proper UI entry points. This is where C++ will benefit you over C. When done right, it is typically fairly easy to turn well written classes into a linkable interface.

    Write your UI in VB.net or C# or whatever. If you did the above right, this should be a minimal effort. It may be difficult if your current VB6 code has the UI code and the "action code" very interwoven.
    Fully separating the UI from the actual stuff your program needs to do is probably the biggest best thing you can do and learn from this. It is by far the biggest "mental leap" a programmer can take onto a path of making better software.


    What you gain by doing this.
    Your "critical" code will be portable (or should be fairly easily modifiable to achieve this) and can compile/run on any OS/compiler/CPU, without sacrificing performance.
    all you need is a custom made UI for each OS. And with a bit of care, even this can be minimized if you take a language/framework that is portable as well.

  9. #9
    Join Date
    Jul 2013
    Posts
    576

    Re: vb.net ... why bother?

    Quote Originally Posted by OReubens View Post
    .net in any flavour (basic, C#, J#, C++) makes your code run slower. you can drop all the BS and attempts at claims otherwise, but this is a given fact.
    Is it a fact and no BS? Fine then prove your claim.

    In my experience the major languages running on virtual machines execute code as fast as any natively compiled language including C++. Any local micro-differences will be averaged out over a reasonably large and complex application.

    http://en.wikipedia.org/wiki/Java_performance
    Last edited by razzle; August 21st, 2014 at 02:57 AM.

  10. #10
    Join Date
    Jul 2013
    Posts
    576

    Re: vb.net ... why bother?

    Quote Originally Posted by OReubens View Post
    What you gain by doing this.
    Your "critical" code will be portable (or should be fairly easily modifiable to achieve this) and can compile/run on any OS/compiler/CPU, without sacrificing performance.
    all you need is a custom made UI for each OS. And with a bit of care, even this can be minimized if you take a language/framework that is portable as well.
    My advice to achieve the same would be to write the whole application in either Java or in native C++ with a Qt GUI.

    Important in both cases is that the application is based on the object oriented and functional paradigms. This will increase performance and maintainability in both cases compared to the procedural approach.

    Both applications will be equally fast, roughly equally portable, and have equal present and future prospects, so that's not an issue. The difference will be the languages themselves. How easy/difficult they are to program and how easy/difficult it is to interface them with your own sub-systems and third party sub-systems such as CUDA, OpenGL, Xeon Phi, high performance libraries, etcetera. In my view Java is better at the former and C++ at the latter. It's a hard choise. I know because I've been there.
    Last edited by razzle; August 21st, 2014 at 03:11 AM.

  11. #11
    Join Date
    Aug 2014
    Posts
    6

    Re: vb.net ... why bother?

    Quote Originally Posted by wavering View Post
    I am migrating because VB6 is being phased out and I cannot install the IDE on a modern Win 8 laptop (I am told it can be done but I have not managed to do it). I am also concerned that in due course ie post 2024, MS will stop VB6 programs being run
    All we know at the moment is that Microsoft say VB6 programming will be supported until 'at least' 2024. That may imply it will be supported beyond then, but Microsoft aren't saying.
    But then, they aren't saying any more for VBdotNet either.

    Just because Microsoft stop "support" doesn't mean VB6 won't continue to run.
    The VB6 support they currently offer is here:
    http://msdn.microsoft.com/en-us/vstudio/ms788708

    The next 'milestone' for VB6 is to find out if it will be supported on Windows 9. It probably will, but Microsoft never say before release.

    I mentioned in another post I have the VB6 IDE running on Windows 7 and 8.1.
    I also suggested looking at Gibra's VB6 installer:
    http://nuke.vbcorner.net/Articles/VB...S/Default.aspx

    If you try a VB6 install (preferably on a clean Windows 8 PC, ie one without a failed VB6 installation on it) and post any issues/errors here I'll see if I can advise you.
    Last edited by VB6 Programming; August 21st, 2014 at 06:36 AM.

  12. #12
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: vb.net ... why bother?

    Quote Originally Posted by razzle View Post
    Is it a fact and no BS? Fine then prove your claim.
    I don't have to proove it. Nobody has ever properly proven the other case.
    So thrown back at you. Write a bunch of java code, and an algorithmically equivalent C/C++ version, and show me the java version runs faster.

    I have only seen a couple of such cases but that was because the java code used features/libs that weren't available in C++, and the method to simulate them in C/C++ was horrible. Or because the "equivalent" C++ library was horrible.

    The only real case I can admit to is if you HAVE TO interface to other java code. In that case the transition from C++ to java and back can certainly ruin you, but this is hardly a claim to performance for java.

    I'll also give you the fact that for a few cases, the java/C# code runs equally well (or close to it) when it's been precompiled to native with a proper compiler/optimizer. Actual bytecode instances and even JIT compilation typically runs way behind.

    If java/c# and the likes REALLY came close enough to C/C++, there'd be an actual non-negligeable amount of production code written for high performance applications, as it stands, that just isn't the case. Excluding various types of assembly, most of it is C and C++, a sizeable chunk is Fortran, then there's various special languages...

    In my over 20years of development in the particular field of optimization/performance, I have never ever even got a single request for "oh, right, we need this in java/C#".

  13. #13
    Join Date
    Jul 2013
    Posts
    576

    Re: vb.net ... why bother?

    Quote Originally Posted by OReubens View Post
    I don't have to proove it. Nobody has ever properly proven the other case.
    Well, if someone claimed Java is faster than C++ (and everything else is BS) I would've asked them to prove that too. When you make a claim you have the burden of proof.

    If your definition of high performance is speed (or throughput) all available evidence shows that Java and C++ are within 10% or so of each other today. Please feel free to provide just one single recent article or blog or test or scientific paper to the contrary.

    In my over 20years of development in the particular field of optimization/performance, I have never ever even got a single request for "oh, right, we need this in java/C#".
    Maybe it's because everybody knows you don't know any Java so no one bothers to ask you about it.

    When Java was introduced 20 years ago one claim was that it was faster than C++ or at least would be anytime soon. It was hype of course and many trustful early adopters suffered severe damage from which many have never recovered. There's still this lingering sentiment that Java is slow and always will be.

    But here we are 20 years later and the situation has improved dramatically. Both the Java static compiler (from Java to bytecode) and the bytecode dynamic compiler within the virtual machine (from bytecode to native) have undergone dramatic improvements in recent years.

    There are many reasons to pick one language over the other but in my book it roughly boils down to this: Java is easier to program and maintain whereas C++ is easier to use with all sorts of sub-systems. Performance wise they're equivalent.

    If you study this, people may start asking you for advice also concerning the possible use of Java,

    http://en.wikipedia.org/wiki/Java_performance
    Last edited by razzle; August 22nd, 2014 at 05:17 AM.

  14. #14
    Join Date
    Oct 2008
    Posts
    1,456

    Re: vb.net ... why bother?

    Quote Originally Posted by razzle View Post
    If your definition of high performance is speed (or throughput) all available evidence shows that Java and C++ are within 10% or so of each other today. Please feel free to provide just one single recent article or blog or test or scientific paper to the contrary.
    because it's just too hard a comparison to be scientifically tested, provided such a thing would actually make sense ( what/how do you measure what ? ). The only "evidence" we have is the avarage reponse of the industry that shows a preference of c++ over java whenever performance/responsivity/etc.. are perceived as core business ( how many leading 2/3d graphics app do you know ? how many quality games ? how many scientific institutions use java for HPC applications ? ... ).

    anyway, here is a paper ( first page of google search, there are many others ) from a google expert dated 2011 showing 3-12 times slowdown in c++ vs java (different flavors) and 3-6 times memory footprint; the conlusions start with a laconic "We find that in regards to performance, C++ wins out by a large margin" ...

    here is another paper ( same google page ) from an italian university ( usually biased in favor of java-like solutions ) showing more than your "10% or so" slowdown ...

    Quote Originally Posted by razzle View Post
    There are many reasons to pick one language over the other but in my book it roughly boils down to this: Java is easier to program and maintain whereas C++ is easier to use with all sorts of sub-systems. Performance wise they're equivalent.
    this is quite contradictory ... as among those all sorts of subs-systems there are subsystems used exactly for performance reasons ( you quoted CUDA, etc.. ).
    Last edited by superbonzo; August 22nd, 2014 at 04:55 AM.

  15. #15
    Join Date
    Jul 2013
    Posts
    576

    Re: vb.net ... why bother?

    Quote Originally Posted by superbonzo View Post
    the conlusions start with a laconic "We find that in regards to performance, C++ wins out by a large margin" ...
    And then it continues with

    "However, it also required the most extensive tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer."

    But that won't be a problem of course since every programmer is above average, at least if you ask them.

    Furthermore (under E Java tunings):

    "Jeremy Manson brought the performance of Java on par with the original C++ version. This version is kept in the java_pro directory. Note that Jeremy deliberately refused to optimize the code further, many of the C++ optimizations would apply to the Java version as well."

    Who knows where it would've ended if Jeremy Manson were more competitive?

    In short the findings are inconclusive.

    could go on and on ...
    And so could I but I won't.
    Last edited by razzle; August 22nd, 2014 at 05:28 AM.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)