In many posts it was spoken about the effect that the xojo IDE is becoming slower and slower. The xojo Team says it is because of the Size of programs. In the confrontation I wrote about it because I was comparing this effect with other IDE’s in a comparable pricing segment so IntelliJIdea and Eclipse.
The Effect is there on Windows, Linux and MacOS in xojo 2020R2.1 and older Releases. When you have a Program with a quite long Sourcecode you can see it really fast.
Foundation for that are the following effects: first the String conversion of Xojo is really slow so when the auto completion is scanning the text, it needs a big Bunch of time to do it. Second the Xojo IDE is comsuming more and more memory. At the End it is so that the Size of the memory Block is also terrifying the Speed of the IDE.
Why it is so? Short Answer: Xojo is written in Xojo. This makes it less complex to get an IDE with less usability problems but it is relying on xojo by self. And because of the slow string management it is slowing down more and more with the memory consumption. Cause xojo misses another thing: a working Garbage collection. As experienced Java and C++ programmer I know the difference. But Java is quite more optimizes so the effects of missing GC is not a thing you will feel.
Xojo at the other side has this Problems. And with a more and more complex programming because of more and more complex features there is not the needed amount of taking care at xojo Site so that this effects can be corrected in the compiling process itself and in the Language itself.
Why the are not writing the IDE in Java or C++? I do not know.
The Xojo IDE used to be much faster. I would say it has gotten slower due to sloppy programming rather than because it is written in Xojo.
Example. On macOS, clicking items in the navigator, selecting controls in the window editor and selecting menu items in the menu editor now has a very noticeable lag. Profiling the code using Xcode Instruments seems to indicate that the IDE toolbar is getting rebuilt on each click (twice in some cases). If you hide the IDE toolbar the situation improves.
Xojo does reference counting garbage collection. It might not be as efficient as Java / C++ but unless their implementation has been getting slower and slower with each Xojo release it isn’t the cause.
Their was in history no xojo written IDE. The beginning of writing the IDE with xojo instead of C++ made it better in questions of usability and worse in Speed.
That the language is more and more loosing it’s ability for Speed is no question because the implementation is not what I would expect. As example I would look on the Mysql Driver. It is Slow. So slow that the same app written in Java is 11 times faster. As I was writing my Apps with xojo in the past years I had - because of Web2.0 - to start writing with Java. And restarting the use of Java is sometimes more work oin coding but never running for working features of the language.
When testing Xojo features and looking how they are implemented I can say it is far, really far away from C++, Java, C or even Lazarus.
If aou start under this conbditions writing your IDE with the language byself you may have more problems.
I started around 2006 which was after they ditched C++ for the IDE. The RealBasic IDE wasn’t slow and previous versions of the Xojo IDE were not slow either. This seems to indicate some inefficient code has been introduced in recent versions.
It’s not surprising that the Java MySQL driver is more efficient than the Xojo plugin. At the same time we haven’t had any real performance issues with Xojo & MySQL that we couldn’t explain and resolve.
I agree that the Xojo framework could be more efficient but I don’t believe it is too slow to be used for the Xojo IDE.
It is not the Slowlyness that makes it not usable for the IDE it is the combination of no Garbagecollection and inefficiency and problems with the consistency of the framework. When disassembling Apps I have written with xojo you can clearly see that the App makes for really simple steps problems.
The MYSQL problems I would never get when I would not have a heavy Load Mysql System outside. When working with much datasets (around 5 Mio. Datasets) where we had to do a type conversion and a string conversion at every customers database to have the data prepared for our own system made it affordable to think about the problems.
And yes: one problem was the Speed of the Database, it was really slow. Is not so interesting when not processing Millions of datasets so for example Select Statements with results of a few thousand datasets where no problem.
The next problem was the string conversion; xojo needed for every Dataset to convert around 3 seconds for getting it from Database, converting it and saving it to a new Database. Java needs 0.17 seconds., Even with workers it was miles away from the speed of Java. We can speak about the really great amount of Java optimization but in this case it is a programming error; the Mysql Driver from MBS was double time fast. Anyhow, most time wás the string conversion eating.
So we reach to the third problem or let’s say: now comes the showstopper. After around 20k datasets xojo was running out of memory cause xojo was not doing the urgently needed garbage collection. So Memory runs out to nowhere.
Coming to String conversion we are also reaching to the functionality of the IDE: when the IDE shall do code completion it has to reach out the code to the compiler. The string handling is REALLY slow, not comparable with C++, Lazarus or Java. In this case xojo has the problem, that, if you have a long sourcecode, xojo has to handle the strings the entire time.
So it comes up to this problems. Starting was this problem long time before, old versions I was downloading to check where doing the same problems. I have Xojo files with a size of 80 MB without any media inside, only sourcecode. When running the IDE and it has to do code completion it is SLOW. To slow to work.
When the memory is running out of it is becoming more and more slow as much the memory is swapped. So you can get out of this problem only with another String Management and another Memory Management.
There is no garbage collection in the same sense java does
Its purely reference counting
When an object has 0 references remaining it is destroyed immediately
But what the system does NOT do is recover any orphaned cycles that cannot be reached any longer like a garbage collector. So if you make two object refer to each other then nil all other references to them they will exist until your application quits. They just take up space.
Autocomplete requires a rewrite IMHO
How it does what it does is why its slow and often incorrect
It can be tweaked to do a better job now but the algorithm it uses to find things is the problem.
There are other issues with it as well that mean it has way too much work to do on keystrokes - and that volume of work induces slowness in typing and other areas
The IDE used to be written in C++ but there were issues doing that.
The theory behind using Xojo to write Xojo is “dogfooding” - you use what you write so issues are exposed more rapidly and fixed more rapidly
To some extent that has worked BUT if Xojo doesnt use the IDE in the same way users do then the issues users report wont be seen. I can say that while I worked there we avoided really really long methods for many reasons. Plugins used were only the ones the IDE needed yet users often have all of MBS & Einhugur and others installed
When the IDE was written in C++ engineers would often NOT be using it and so they would not see the problems
They switched to writing the IDE in Xojo around 2005/2006
I agree code completion is slow today but it used to be much faster even with 40 plugins installed. From conversions with people who have worked on the IDE my understanding is that code completion is all within the IDE and doesn’t touch the compiler. This means that either the framework got slower or the code completion IDE code got slower (ie: inefficient code).
Java strings are immutable like Xojo strings. If the difference in string performance was when concatenating it could be because Java sometimes optimises your code to use StringBuilder which is similar to appending strings in a Xojo array and then joining them.
I don’t think we have ever selecting 20K records from MySQL but we have selected 20K records in SQLite which are then transformed before being inserted into MySQL. I haven’t seen any out of the ordinary memory requirements when doing this. Maybe there is a difference in how Java & Xojo interacts with MySQL regarding result set buffering meaning that the entire result set was being held in Xojo memory.
I personally like reference counting. Xojo makes it pretty easy.
In saying that, I have also found that Apple’s AutoRelease to be incredibly useful when it comes to performance. When I wrote a video processor using AVFoundation two years ago. I would release each frame after it was added to the video encoder. When I switched it to use autoRelease and controlling the pool. I found I could release 30 frames in the same time it took to release just one frame. Which made video processing as fast as some commercial apps.
So I can see a benefit in GC, but personally just feel that retain/release to be more logical and straight forward. You retain it for as long as you need it, then release it when you’re done. (I know it’s not that simple).
You do not say the amount of hardware memory, free SSD space, size of the offending (slow) project, the length of the session since Xojo launch until you quit, etc.
And another thing is forgotten (above) is the Cancel feature: work for 10 hours, then press the Cancel shortcut for your platform (Cmd-2 or Ctrl+Z) and wait until you cancelled all of your 10 hours of work.
I really do not know how the Cancel feature (nor the Xojo IDE) is coded, but it certainly takes memory, too many memory.
What was not said too is… how many other applications run concurently to Xojo (DVB software to watch Tennis / Football / Naked woman (!), etc.) what are-you uploading or downloading, and so on.
It is slow now here too (El Capitan Xojo 2015r1): go figure… I am quite sure Xojo is not the cause / the real cause is elsewhere !
No Plug-In here, but downloads / near to full SSD / DVB (TV running on an external monitor)…
Have you made a test with a brand new comuter running only Xojo / no plugin / no internet / plenty of free room in the SSD and a 5KB project ?
Just for the sake of telling: “Xojo is slow” or “I do not code like that” (but in this case, try it, then give answers).
Xojo was gettin above 14 GB Memory use. Thats to much sorry. With every operation memory was growing. It was a repeating operation, no new objects, all variables where reused.
Machine: Ryzen 9 with Windows 10 and Linux Ubuntu Focal Fossa, 32GB Ram, 4 TB SSD. More Questions? And yes: comparing to Java (I am programming dayly Java Swing applications) xojo is in all competitions really slow. Sorry to say that but there is no way for xojo to be comparable in performance with Java or with Lazarus.
And be sure: xojo is the cause. On our Linux Machines, on the Windows Machines and on the Mac Machines it is the cause. Our Java Applications running muich much faster.
I have tested Xojo on a brand new Windows Machine, Ryzen 9, 32 GB Ram, 1 TB SSD. And the Same I done with Java. Guess what? XOJO IS SLOW! And you will not speak xojo faster. They have done many mistakes within the last years. And it is like it always was: all mistakes over the time are becoming a mounted machine and costing performance. I have to long time experience as programmer to believe that xojo is not the case. Sorry but I tested it on more machines (all in my company used development computers) and I tested it with brand new hard disks.
And for what I shall test 5 kb Sourcecode, our smallest projects starting with 30 - 40 MB Sourcecode. 5 KB is nothing. If you use Xojo with 5 KB it looks fast and okay. Start to really professionally use it. You may get what I mean.
That’s my foundatiuon for switching our Applications to Java Swing.
every “action” is recorded - the data required to perform the action and the data required to undo it (along the lines of the command pattern - there are other ways of doing this as well)
So each thing you DO is saved so it can be undone and redone
And depending on what that is it can be a lot of data or very little
But you need some data so support do/undo/redo
There’s no avoiding that
Are you running your App in debug or are you running it in a compiled version?
Our compiled application process milliions of datasets over the day and we do not see any memory problems, unless we didn‘t implement memory leaks by our selfs.
The model to release memory after it references shrunk to 0 is very smart and a garbage collection is not needed, if your own code works well.
Other thing:
if your variables grow to huge amounts, better write them to the disc instead of keeping it in the memory.
We also use for example a RedisDB to store things temporary. If your computer runs on SSD, you shouldn‘t see a performance drop with this method.
Last thing:
if you complain about performance, then simply don‘t use Xojo. For high performance and parallel tasks, we use Node.js. Each tool has its advantages and disadvantages, your part is to choose the right one for the right task.
I believe that bugs & performance have pushed @thorstenstueker to Java
Java is extremely well tested and robust and has a huge number of classes that can be used for just about any task
But its not perfect for every task depending on circumstances
In Release Mode on a freshly installed OS. I would never try to run it in Debug Mode with this kind of Database Usage. Get it. It is simply Slow, buggy and not working for professional production. That I had to learn in my Xojo experience. Only thing you will do is pay for xojo. Not more.
and by the way Lars: the App is running in production as Java App without all of this problems. It would run as we would run it over the day with less then 15 Million dataset conversions. But we need the conversion immediately and fast and not within 24 hours. That’s the fundament of the decision.