Hello coming from vb6. I would like to get some feedback on how you think performance differs from vb6. My app controls hardware through a usb interdace and needs constant updating along with a very complex gui modifying 1000s of traits a second. Anyone here have a similar situation, how would you compare performance if a xojo compiled app. Also anyone know what us under the hood of xojo, does it convert to c or c++ then to machine code lije vb6? , thanks in advance.
my understanding is the VB6 is NOT a NATIVE compiled executable, but closer in fact to a P-Code interpeter… while VB-NET is compiled to native machine code, as is XOJO.
And I will put money on XOJO out running any VB6 code doing the same task on the same machine with code written is a similar manner.
Im am 90% sure the opposite is true, vb6 can and does compile to a native exe, and .net is interpreted at runtime like java. Not an expert though. I would hope xojo does not compile like .net.
Dave, VB4 and higher were real executables. VB3 was pcode. In fact, VB6 and VC++ at one time shared the same compiler.
My real life applications perform roughly at the same speed for comparable functions in VB6 or in Xojo. This appreciation is certainly not to be construed as a scientific benchmark.
Actually VB4 was still P-Code… while VB5 and VB6 both compiled to native x86 instructions.
However VB.NET seems to have taken a step backwards… .and while it is not “p-code” it might as well be… it is now “CLR” or “Common Language Runtime”… this allows all the Microsoft .NET languages in Visual Studio to share a common execution mode
The Common Language Runtime (CLR) is the virtual machine component of Microsoft’s .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time compilation, the compiled code is converted into machine instructions that, in turn, are executed by the computer’s CPU.[/quote]
[quote=42670:@Dave S]Actually VB4 was still P-Code… while VB5 and VB6 both compiled to native x86 instructions.
However VB.NET seems to have taken a step backwards… .and while it is not “p-code” it might as well be… it is now “CLR” or “Common Language Runtime”… this allows all the Microsoft .NET languages in Visual Studio to share a common execution mode[/quote]
CLR - think more like “java runtime” - although not identical it’s similar
Similiar performance between my 12 year old VB6 application and the converted version in Real Studio. Xojo, I find a tad slower, but nothing I would term critical. Probably just my code is more or less optimized for RS, and Xojo will just take some time to get there (although every time I mention this, Xojo engineers act surprised. Sorry, just doesn’t produce a binary with the same performance).
Most times you’d have to have hand optimized things like invariant subexpressions, unrolled loops or retained references to intermediate values and such to get closer.
The current compiler doesn’t do a lot of optimizations like that.
Compared to the VB6 program or the RS program? I was expecting the Xojo compiler to build it the same as the RS compiler or at least close, and that just has not been my experience.
The RS compiler & THe Xojo ones are, at this point, the same compiler.
Once we move to LLVM then the Xojo compiler should do a lot better optimizations (which you can get a feel for is you already use XojoScript which uses the LLVM based compiler)
Right, but know that I was expecting the IDEs to be able to build the same EXE. I’ve discussed the issues before, just does not produce executables that behave the same. the same exact app is about 10-15 % slower with Xojo and the Einhugur Style Grid pops up much quicker than the rest of the UI elements on the same screen (In RS it all appears together). I talked briefly with Einhugur, he said he has no control over when the framework updates the grid and shows it.
Really I don’t want to pursue this now, I’ve got a lot of work to do and RS is OK for now.
I’ve noticed the same thing. The difference isn’t compiler, but framework. It is possible that the framework changes will be optimized over time, or they’ll just wait for LLVM to optimize for them. But it’s pretty typical for new code to be less optimized, more lax, and more bloated than old, well-honed code. Give it time.
This is only a step backwards in terms of source code security. .NET applications have traditionally been easier to decompile then native binaries, and the output has been more meaningful and useful. (Though I would sear I read that Microsoft was going to address this. Have they?)
From a performance standpoint, the CLR incorporates a lot of optimizations we’re still waiting on. .NET code is not slow.
I’d like to be the first person to actually answer the posters question. =) (Forgive me if I misunderstand, the poster didn’t initially mention anything about .NET. He asked about PERFORMANCE and I’m answering it.)
My main bread-butter-money app used to be in VB5 (same as VB6 really). It is faster than REAL/XOJO by quite a bit. Every so often I go back to the code base and fix a couple things and I tell you running it is such a pleasure compared to the behemoth that REAL/Xojo is. It’s is fast and speedy and light and feels like you are coding on air.
Plus the debugging is so much easier and most apps start up way faster. I didn’t do too much drawing but I have a feeling the drawing is faster too, plus you have the free ability to call API (which you can do in REAL/Xojo but I’m not sure if it helps). I never had the flicker issues like in REAL/XOJO.
I use REAL/Xojo for the cross-platform ability, plus REAL/XOJO is way ahead of VB6 as far as inheritance and supporting and encouraging better software design. It was a compromise to walk away from VB and adopt REAL/XOJO but I don’t regret it at all. I hedge performance issues by using a C++ DLL whenever I can, whose functions can often beat REAL/Xojo 10:1.
There’s no reason to not continue using VB6 because it’s 15 years old. If it works for you, if you don’t need xplat, and you don’t mind lack of inheritance, stay with VB6. There are many VB users that balked at moving to .NET and many have no regrets at all.
Lastly, to correct the record, VB5 and VB6 can compile to P-Code AND Compiled apps, you have a choice. When you are debugging it’s always P-Code. There is always the warning that there may be some bugs and ambiguities in the compiled app that you don’t catch debugging in P-Code, but that’s very, very rare. (And yes, I believe the linker is the same as Visual Studio’s, only jury-rigged for VB.) For me, I like using the compiled app for my production copies, but it sort of doesn’t matter. As Microsoft said, they only really did it to pacify people that complained about it. It really was only a perception issue. It all winds up being an .EXE that works off of the Visual Basic Virtual Machine msvbvm50.dll or msvbvm60.dll, the user doesn’t know the difference 99.99999% of the time.
Thanks Garth Hjelte,
I really appreciate your comprehensive answer.
I really don’t want to switch because of the great, fast IDE. And after 10 years, I got pretty good at it. My software involves lighting control and radio automation.
BUT, I am worried that when vb6 apps stop working, ill be stuck. I feel I need to prepare now for what my options are when that happens. I hope when that happens I have at least a year from preview release, to retail to re-write.
My apps are also my bread and butter, I am a one man shop.
Thanks again Garth, you have clarified things for me.
How well did VB5 and VB6 run on OS X and Linux? I never tried it.
VB is a windows-only tool. I once looked Wine on Linux to find a way to use and distribute my apps on Linux. While some apps could run, the IDE could not. The process to make things work was too complicated to consider distributing on Linux. That may have changed by now, it was a few years ago.
I decided to look for alternatives when I found that I could not use the IDE under Windows 7. I had to resort to a virtual machine running XP or Vista. I went withan XP mode VM. Recently, I had trouble with one of my VB apps that refused to run under Windows 8. To date, I have not completely figured the problem out. I enjoyed VB6 and can relate to the comments made with regards to “coding on air” and IDE agility. VB6 was an excellent tool, that unfortunately appears to be reaching the end of its general purpose life. I do miss the comfort of the VB6 IDE quite a bit in Xojo. But Xojo gives me cross platform, does make apps that run under Windows 8 (or pretty much any version prior). So, Xojo it is going forward.
I’m joking around, of course. I’ve done plenty of VB programming myself. My point being, the RS/Xojo team has done one heck of a job optimizing it on multiple platforms. BTW it might be just me, but I find the Xojo GUI to be much more fluid on OS X than on Win 7. Whenever possible I try to code on OS X even if I’m compiling for Windows.
Are we talking about IDE performance or built applications? The discussion side tracked because people often associate performance with native binaries. As I point out with .NET that assumption can be false. And .NET would presumably be another option for Winston.
As to IDE…I don’t want to side track into a RS vs. Xojo discussion, or a Mac vs. Windows discussion, but Real Studio 2012 was fast on Mac OS X, and I still use it for most of my projects.
Final application speed depends on so many factors that it’s pointless to try and guess which IDE or framework/compiler will yield the best results. You have to benchmark the framework pieces you will be using and the type of code you will be compiling. Software architecture and quality of code will often trump any such differences. But sometimes the differences are very important. If you know what you’re doing you can make C++ code run circles around Xojo, VB6, and .NET on certain text/data processing, for example.
Winston - from your initial description, if there’s anything I would test it would be the GUI updates. What do you mean when you say “1000s of traits a second?” Are you updating a handful of controls as fast as possible? Changing 1,000 controls? Drawing information directly to screen (i.e. a graph)? Once a second or as fast as you can?
Oh yea, I meant IDE performance. Thanks for catching it. Much more fluid on OS X.