Why are C++ plugins necessary?
Shouldn’t compiled Xojo execute as fast as C++?
There are a lot of people who laugh when I say I like to write my apps in Xojo, but I will always lose this discussion when it comes to the speed of compiled code.
I might understand if the final executable was an interpreted byte code, but it isn’t.
On a side note… Why wasn’t the Xojo IDE written in Xojo?
Well perhaps it has something to do with not having the widgets that the IDE are made from available to me as a developer.
One would think that you wouldn’t have used 3rd party widgets to build and IDE that you don’t provide to your users.
Or am I mistaken?
I agree that there is a lot of stuff in there that should be standard controls. The on/off slider, splitter, the tree thing (or whatever it’s called) on the left, search box etc.
However, (although not easy) I think everything can be made with Xojo.
What things did require you to use 3rd party C++ widgets for what wasn’t possible to build in Xojo?
Just curious.
And as for 64 bit Apps that should be the same as Xcode compiled Apps, I’m pretty sure it’s not.
There are tons of undocumented things that when done one way are faster than done in another way.
Like x = y * y is twice as fast as x = y^2. Or Module properties (globals) are x times faster than App.Properties.
It seems that LLVM isn’t optimizing enough to fix those differences.
C++ plugins aren’t necessary for the average user. My understanding is the Xojo compiler is technically a plugin to the IDE like any other. Xojo provides native UI components which expose libraries in C/C++ so it makes sense they use C++ at the lowest levels.
Xojo to C++ speed comparison is not precise unless you write an app in console mode and use pragma’s to disable Xojo features. It provides a lot of safety and convenience features you don’t get out of the box with C++. Those features, abstractions (some leaky) have a performance cost.
As for why controls implemented in the IDE are not universally available… well not every control was built to be distributed and documented. Some aspects of the IDE were built to be part of the IDE and don’t have an API compatible with general usage. I’m sure if enough people asked for a particular control they could work something up in a release or two. You could however implement that same control yourself in Xojo, or as a plugin so whats the difference?
Xojo like any language has its trade offs. You give up some speed and performance for safety and ease of use.
Actually no, Ford and Chevy would not, as they don’t want competitors…
but more to the point… I believe this was raised before, and the response was partially that these “custom” controls in the IDE are just that “custom”… they were not created as “generic” controls, but were designed for the sole use of the IDE
A given “method” written in “C” would not compile to the exact same result as the same “method” written in XOJO (or any other language for that matter). It boils down to the pre-processor, the coding methodology of the developers etc…
Note I saind “not necessarily”… that doesn’t mean that they both could not be the same speed… its just that its not “a given”
[quote=267910:@Brian O’Brien]Well perhaps it has something to do with not having the widgets that the IDE are made from available to me as a developer.
One would think that you wouldn’t have used 3rd party widgets to build and IDE that you don’t provide to your users.
Or am I mistaken?[/quote]
Although I am not privy to the IDE code itself, Norman Palardy has shared several times that what looks like external controls has been created with Canvases. When I look at the IDE, I see nothing I could not obtain with Canvas and/or a few declares. The most complex part of the IDE which is the code editor, is itself made with the Text Input Canvas plugin Xojo makes available as a community resource.
Of course all that requires a good level of Xojo programming.
What Dave S said above was going to be my first point, but he beat me to it.
In addition to Dave’s notes, faster solutions may be possible in C++ than in other higher level languages such as Xojo, Java, etc. C was designed to be closer to the hardware. As the language evolved into C++ the emphasis was still on efficiency at the expense of ease of use. For some algorithms this gives a distinct advantage if you know how to exploit C.
As discussed in the thread Migrating from RealBasic (RB2008 to Xojo) Xojo is making a trade off between LLVM optimization and compile times. I don’t know the specific issues involved, but for some reason having LLVM attempt all optimizations causes excessively long compile times with Xojo. Norman mentioned compile times that “ran for days.” Hopefully this is something that will improve with time as Xojo works on their portion of the compiler chain.
Most applications sit on top of a stack of APIs, libraries, frameworks, etc. Any particular object or function in the Xojo framework may be roughly the same, faster, or slower than comparable functionality in another framework.
All of that said, XojoScript with full optimization is pretty close to C.
Language speed is relevant in certain situations. There are times when you can achieve performance in C++ that you simply cannot in other languages.
But more often than not it is swamped by software architecture.
I’ve had a couple instances where someone said Xojo was “too slow” only to have my final Xojo solution blow out their existing or proposed C++ solution. Could I have squeezed out even more performance in C++? Probably. But the major gains in those cases came from efficient solutions to the problems and not from the language or compiler.
As for the level of attention, any software deserves more love. I don’t think programmers will ever be satisfied. Art is never finished, only abandoned, said Leonardo da Vinci.
I wish it was as well. I certainly have some complaints (like with any developer tool). But Xojo is excellent when it comes to rapid development and cross platform desktop support. Comparable cross platform frameworks are much more expensive and with none of the ease of use / RAD features.
And thinking about speed…a lot of places are using slower scripting languages as RAD tools when Xojo would give them better performance and much better tools for building a complete GUI application.
Xojo is not a “higher level language” compared to C/C++, neither is Java. The only real difference is object orientation. If the compiler infrastructure is the same (and if the developers at Xojo Inc. using it do it right), the result will be the same speed. Java is different as it compiles to the Java Virtual Machine and not to machine code.
Wrong, Xojo was designed to shield you from the hardware more than C does. But this is mostly due to object orientation. For example in C++ and Objective C you can access the structure representing the object instance. In Xojo you cannot. If Xojo would give you access to it’s underlying memory model of Xojo classes there would be no difference in what you could achieve in terms of “being closer to the hardware” within an object oriented language.
C didn’t evolve into C++. The developers of C have nothing to do with C++. And the developer of C++ has nothing to do with C or its evolution. By the way C++ was initially called C with Classes. What makes C++ slower than C is more or less the same what makes an object oriented version of BASIC slower.
Yes and no. Yes in certain cases for a Xojo developer. No, for the developers working on the Xojo compiler.