Why Xojo?

  1. ‹ Older
  2. 4 years ago

    Geoff P

    28 Jul 2015 Xojo Inc Austin, Texas

    @shao s Is the new framework almost complete for desktop?

    No, it's almost complete for the console, but not for the desktop just yet.

  3. Geoff P

    28 Jul 2015 Xojo Inc Austin, Texas

    @shao s Isn't VB a BASIC language?

    Well yes and no. I agree with others about the heritage aspect but what people most care about is productivity. If people see BASIC as being the original BASIC and they associate that with Xojo, that would be a wildly inaccurate association.

  4. William J

    28 Jul 2015 Pre-Release Testers

    I agree with the assertion that you will be more productive in the language that you are more comfortable with. For me, it used to be C++. Now it is Xojo.

    But there is another facet of the argument that should be discussed. For most applications, you spend more time in maintenance and updates than the initial development. And once you finish the initial development you are more or less committed.

    My current worrying issue is the speed of the final application. If I had developed it in Xcode, it would be 20-30x faster and now I am stuck. The last algorithm that I completed is an Elliptic Curve Factorization routine which is very math intensive. I modeled the routine in Sage (a popular open-source math environment) and converted it faithfully in Xojo. I am now very, very disappointed with the performance. To factor a 26 digit integer ( with two nearly equal 13 digit prime factors) takes about 1.9 seconds in Sage and a whopping 87 seconds in my Xojo routine. Since I had good success in developing a dynamic library of helper routines in Xcode for my floating point library I anticipated similar success in doing so again with this integer routine. To my surprise, converting some of the most CPU intensive sections (add, subtract and multiply) to C++ calls made very little difference (maybe 3-5 seconds overall). Now to be fair, Sage is mature product and it even employs a certain amount of assembly language (but not multi-threaded). But, my routine is embarrassingly slow now and I am at odds at what to do next. After much profiling, I have concluded that Xojo performance is dismal in cases of routines with very high volume of function calls. In the case of the before-mentioned routine it calls arbitrary precision add, subtract and multiply routines over 8 million times each so it's a game of microseconds per call and it seems that the C++ call overhead overcomes the benefit of faster C++ code.

    It seems like the wait for LLVM and 64 bit is taking forever and my patience is running out. Joe has indicated that Xojo will never be as fast as C/C++ but I think that the Xojo developers should catch the I won't be satisfied until Xojo is as fast as we can make it and try to get it to a 2-3x differential at least. Wouldn't it be wonderful if Xojo could market the product with ("nearly as fast as Xcode with the productivity of the best RAD tools").

    So my put on this forum argument is: "its not just how fast you get there, it is how happy you are with with what you have achieved once you are there". The thought of converting all of my code to Xcode is daunting and depressing, but I may have no choice. At one point I was interested in multi-platform but now I only develop for Mac. That is an advantage since I will only have to purchase a single desktop license going forward, but the urge to convert to Xcode will always be present as well.

  5. Joost R

    28 Jul 2015 Pre-Release Testers, Xojo Pro The Netherlands

    A year ago I met a company (director and developer) moving from Windows VB6 to Xojo for their CNC - production programs. Last May they told me they had drop Xojo already because it was just too slow for their big amount of math-calculations, where VB6 was appropriate but not supported anymore.
    They chose replacing Xojo for Delphi. Unfortunately.
    Think this and Williams' story show the need for the new compiler

  6. Dave S

    28 Jul 2015 San Diego, California USA

    or need to rethink application design in some cases......

    XOJO (on the right hardware) should be plenty fast enough to handle most CNC applications....... especially since the computers that ran those machines orignaiilly are barely faster than an abacus .

  7. Geoff P

    28 Jul 2015 Xojo Inc Austin, Texas

    @William J It seems like the wait for LLVM and 64 bit is taking forever and my patience is running out.

    Well FWIW, 64 bit and LLVM are coming VERY soon. This would not be the time to jump ship.

  8. Doug S

    28 Jul 2015 Vancouver, Canada

    If I may ask some potentially obtuse questions - what will the LLVM compiler bring in terms of performance of the code?

    Is 64-bit part of a performance boost or just to come into line with industry standards?

  9. Norman P

    28 Jul 2015 Xojo Inc, Pre-Release Testers, Xojo Pro Seeking work. npalardy@great-w...

    64 bit is because all the major OSes are moving there
    And users are pushing their OS vendors to go there
    People want access to the great gobs of memory they have in their machines and you require a 64 bit OS to do that
    And for apps that are 64 bit it means you can manipulate huge images, lots more data etc
    So all the OS vendors are moving there and largely dropping 32 bit support
    And apps are following right along with this move

    64 bit doesn't imply any speed boost and may in fact be slightly slower as everything is twice the size as it used to be

    LLVM being an optimizing compiler it should produce faster code
    How fast depends on the nature of your application

  10. Geoff P

    28 Jul 2015 Xojo Inc Austin, Texas

    To add to what @Norman P said, the more math-intensive your app, the more benefit you will gain from LLVM. If your code is mostly calling into the Xojo framework, it may not get much faster because that code is already compiled by an optimizing compiler.

    However, if you've made mistakes, LLVM may correct them in your compiled app. For example, if you have a loop that is empty, LLVM may remove it entirely. I don't personally know all of the optimizations that LLVM does but that's just an example.

    OS vendors are adding 64-bit only APIs so we really need to go to 64 bit to future-proof apps.

  11. Doug S

    28 Jul 2015 Vancouver, Canada

    I, for one, am looking forward to future releases.

  12. Beatrix W

    28 Jul 2015 Pre-Release Testers Europe (Germany)

    @Geoff:
    Here is an example for the new framework: 2-3 weeks ago I had to convert a memoryblock to string in a declare. Because I'm blind I didn't see the correct constructor in Macos lib. For some reason that I don't remember I couldn't use the old framework. So new framework it was. The documentation showed me nothing. I had to look at the forum to get this:

    Function ToString(extends dst as Xojo.Core.MemoryBlock) As String
    return(CType(dst.Data, MemoryBlock).StringValue(0, dst.Size))
    End Function

    Do you really want to tell me that this is easier to use? I will call in convoluted and confusing.

  13. Eli O

    is not verified 28 Jul 2015 Europe (Berlin, Germany)
    Edited 4 years ago

    @Beatrix W Do you really want to tell me that this is easier to use? I will call in convoluted and confusing.

    But that's because the old and the new framework are mixed. If you'd use Text instead of String you'd use

    Dim t As Text = TextEncoding.UTF8.ConvertDataToText(mb)

    Pretty clear, easy, readable and type safe.

  14. Michel B

    29 Jul 2015 Pre-Release Testers RubberViews.com
    Edited 4 years ago

    @Doug S If I may ask some potentially obtuse questions - what will the LLVM compiler bring in terms of performance of the code?

    We already can have a glimpse, as XojoScript uses LLVM. A while ago there was this benchmark between Xojo and VB6 where I fed the test code to a XojoScript. Results were most impressive. Xojo code in the original test gave 0.7 second. The final test in XojoScript went down to 0.24 seconds. Close to 3 times faster.
    https://forum.xojo.com/14123-xojo-benchmark/0

    Of course, a benchmark just gives an idea. Real life code may lead to different results.

  15. Beatrix W

    29 Jul 2015 Pre-Release Testers Europe (Germany)

    @Eli: that's way better. Thanks! It's still not very obvious because I was looking in the memoryblock section of the documentation.

  16. Eli O

    is not verified 29 Jul 2015 Europe (Berlin, Germany)

    Directly after the listing of the MemoryBlock members there is a Notes section. The first sentence is:

    To convert Text to a MemoryBlock, use TextEncoding.ConvertTextToData. To convert a MemoryBlock to Text, use TextEncoding.ConvertDataToText.

  17. Markus W

    29 Jul 2015 Pre-Release Testers #JeSuisHuman New Zealand, Auc...

    @Geoff P Well FWIW, 64 bit and LLVM are coming VERY soon.

    Do both work with the old framework?

  18. Ulrich B

    29 Jul 2015 Pre-Release Testers, Xojo Pro Answer Europe (Germany, Berlin) · xo...

    @William J My current worrying issue is the speed of the final application. If I had developed it in Xcode, it would be 20-30x faster and now I am stuck. The last algorithm that I completed is an Elliptic Curve Factorization routine which is very math intensive. I modeled the routine in Sage (a popular open-source math environment) and converted it faithfully in Xojo. I am now very, very disappointed with the performance.

    From what you write, William, it sounds like you are developing for OS X? In my opinion, you will almost ever lose when you try to mimic a highly optimized library with pure Xojo code – Xojo's default focus lies on security, adding overflow and range checks (if you don't tell Xojo not to) which of course add some overhead to your project. Have you tried to declare into the Sage library from your Xojo project? Or, if my first assumption is right, wouldn't Apple's Accelerate framework offer the features you are looking for? Using it can easily speed up complex mathematical computations by factor 10, 20 or even more.

  19. William J

    29 Jul 2015 Pre-Release Testers

    From what you write, William, it sounds like you are developing for OS X? In my opinion, you will almost ever lose when you try to mimic a highly optimized library with pure Xojo code – Xojo's default focus lies on security, adding overflow and range checks (if you don't tell Xojo not to) which of course add some overhead to your project. Have you tried to declare into the Sage library from your Xojo project? Or, if my first assumption is right, wouldn't Apple's Accelerate framework offer the features you are looking for? Using it can easily speed up complex mathematical computations by factor 10, 20 or even more.

    Ulrich,

    I now develop for OS X only. But I only decided to do so in the last year. I originally desired to be cross platform. I started by developing a plugin for Livecode (while my laptop was still Windows!). While this worked pretty well I was not satisfied as I had to create arbitrary precision objects by converting to/from strings and that killed a lot of speed. I was drawn back to Xojo ( I went back and forth for several years as far back as 2002) due to features that would allow development of the code in pure Xojo (principally memory blocks). After creating a pure Xojo capability, I was disappointed in the speed so I created a C++ library to call into to compensate (lower level functions to accelerate add, subtract, multiply, divide, compare, ...). The C++ library approach worked really well for floating point arbitrary precision work. So good in fact that it is significantly faster than Bob Delaney's library for almost all functions. Over the last year I have begun the development of a Big Integer capability to complement the floating point capability. What I have discovered is that the most interesting integer functions (such as factoring) require a huge number of calls (with a small amount of work per call) as compared to the worst case floating point functions. For instance, I can compute Pi to a million decimal places in just a few seconds (under 10) but as I pointed out above it takes 80+ seconds to factor a relatively small number. The computation of Pi requires less than 10 iterations of C calls versus 8+ million for the factoring. The issue then relates to the time spent in C routines versus Xojo methods, plus the overhead of calling the C routines themselves.

    I have avoided calling open source libraries for two reasons. I wanted to learn everything I could about arbitrary precision (it became an obsession) and second I want to avoid GPL licensed code since I wanted the option to be closed source and be able to commercialize it.

    One option that I have is to create a C based Xojo plugin where I could do more work on the C side (i.e., call a factor() function versus having the logic in pure Xojo). But the work to create the plugin would be about the same as converting the whole shooting match to something like Swift.

    I have already enabled the pragmas in the Xojo routines to disable bounds and overflow checking and so forth. It makes very little difference.

    I am much more speed sensitive since I have commercialized a calculator based on the floating point capability and want to do the same for integer functions. While it was just a hobby, it was more of a learning thing and speed did not matter as much. The new compiler is just what the community needs to build high performance commercial applications. I'm just hoping that it will be fast enough for my needs. If not, I am a competent C language developer and can explore other options. I really would like to stay with Xojo since I enjoy coding in it so much.

    Btw, Sage is a pretty amazing product that uses Python as a scripting tool that calls into multiple math libraries. Its amazing how fast an interpreted environment can work.

  20. Ulrich B

    29 Jul 2015 Pre-Release Testers, Xojo Pro Europe (Germany, Berlin) · xo...
    Edited 4 years ago

    Thanks a lot for taking the time to explain so exactly, William!
    So the bottleneck is indeed the overhead that goes along with the C calls. I see that's hard to handle. The only thing that comes to mind (besides waiting for r3) would be to use XojoScript for the computation. Then, again, switching to XojoScript adds some overhead too, so it would probably be better to shift the whole computation into a script, and it has limitations that may forbid such a solution. But probably you have tried that already too, I guess?

    And you're right: Using the compiler pragmas usually is no real booster. It's impossible to tell in advance how much speed LLVM will add, but I keep fingers crossed it will be a valid solution for you. Please keep us informed.
    Oh, and Sage: Most of what it contains is way above my scope. But it sounds really impressive, especially with the speed you describe.

  21. Geoff P

    29 Jul 2015 Xojo Inc Austin, Texas

    @Markus W Do both work with the old framework?

    Yes.

  22. Newer ›

or Sign Up to reply!