Thanks, everybody, for your interesting replies.
Now, I want to reply to Normanās quote:
āNow, do I think Xojo WILL do anything?
Noā
I like to reply:
āBut they should do something about it, right away!ā
But I agree with all of you, Geoff will never listen fairly to us, whatever we say.
llvm is never a native compiler it is always a compromise with a sublanguage used as frontend.
Yes but the use it as it shall be used and in a really optimizes way. Rust has non llvm compilers, Go also. They have the experience and they exactly know how to use it. The difference is knowledge. Xojo has not the needed knowledge. Using the Frontend Language for llvm needs a big pile of special knowledge and that is something you need selling a construct like Go, Xojo and others. and even if they had Ideass before years there is a small news: technologies changing and that changes of the last years Xojo could not use. No Compiler knowledge in the entire company.
Makes no difference for the user again. It is a dead end. They can not change all of this bad stuffs. They have no know how in that case or at least not enough know how.
You canāt do that without compiler Support. Short answer from one which knows how to write it and how to do it. We have compiler Guys in my company while supporting more than 4 language compilers from our Services here. And they say: Nope will not work even if you are so strongly believing. Nope. Thread supporting has to be implemented in the compiler also otherwiseā¦sead end. The GC is another animal for this you need to change the language massively and not the frameworks only. People which believe that - following to Dr.Dr. Gier our compiler guy - have not an Idea of LLVM. And yes, I believe him while he was paid by a big Vendor for LLVM Supporting. He knows LLVM exactly.
Strings are only one problem, match is a problem, integer handling is one, double handling another one. Oh Man, wide area of struggling with framework, language and compiler. Wide, wide field. Specialists for the fields are needed.
What I know is that what my team knows. And I believe they know a big amount. Analyzing what Xojo sends to llvm and what results after is one thing helping to get out what Xojo is in real. And that is dangerous while dead end. They would have to do a lot outside all their Bugs. But they canāt. There are definitely changed needed in compiler Backend. Again: I believe more in an llvm Specialist than anybody else. When he says: look here the code is nonsense then the code is nonsense. And given to the compiler. And compiled. That us not what produces performance. Sorry. I am more informed than you think I guess.
But in one point you are right. I am only inside of develop tin virtual machines. Like the rebuild of a new Version of the Java ā Objective-C Virtual machine for JavaFX. We can speak about compilers. Itās also inside the VM. Something I have knowledge about. Not about LLVM. Java cannot be compiled by LLVM as we both know.
But you talk based on opinions and asumptions, very scientific 
Even if we believe in the willing. We MUST realize also that they can not. That is the sad fact. A compiler vendor without Compiler programmers is what? A code copier for years? That was never working and always the end of the chain.
Someone there IS tweaking it occasionally
And someone is writing the transpiler for Xojo Android
Probably more correct to say ālimited knowledgeā
But thats not the only impediment (again - insider knowledge)
Iād agree IF what they do now, reference counting, WERE an issue
Its not
At least its not the source of the issues in the frameworks and IDE
You did read what I wrote ?
I dont advocate them adopting GC FWIW
Strings are an internally implemented data type - it IS an immutable type
And yes there are issues (which is why TEXT was created but then thrown away - sadly)
Integers though ? Doubles ?
Theyāre to spec IEEE integers and doubles and handled in the CPU so I really have 0 ideas WTF you mean here ?
All the basic numeric types are IEEE conformant
Currency though - THATS a different beast
From the outside unless they decompiled the compiler & watched exactly what it does to produce its output
They might know a lot about compilers etc but they dont know Xojoās implementation of LLVM, its front end, etc
And THAT is crucial to know WHY Xojo doesnt turn out code that is a performant as other languages that DO use llvm and why certain optimizations cant be used
Right but what he CANT tell you is HOW that code came to be that nonsense
I can 
I know those internals and why what gets sent to LLVM IS the way it is
and THAT is vital to understanding WHY that LLVM code IS nonsense
No youāre exactly as informed as you can be
But thats still limited
Dunno if Iād say ācant beā
Hasnāt been is probably more correct
Since ā¦ why ?
There are already good compilers for java so why write yet another ?
Some projects do exist - like the polyglot compiler that turns java into LLVM IR but its one of a handful of niche type projects
Thereās just no reason to implement yet another compiler for java unless there are significant advantages
Now there ARE JIT compilers (like Azulās falcon) that IS LLVM based
So its not impossible to think that a Java compiler based on LLVM would be possible
But again ā¦ why would anyone do that ?
They been without a compiler engineer at least a couple times
Each time the company has survived
This time ? remains to be seen
To me async/await is just a syntatic sugar and I personally donāt care about it that much. I do agree that good parallelism support makes everything a lot easier and gives performance boost almost for free.
it might(!) help even you when working with the IDE 
Simply integer Operations handled in the CPU are in Xojo much much slower than in C, C++, Javaā¦ and the rest. Means: something is fishy. Thatās what I mean. Even that you can crash
It makes no difference if you know that. They canāt change that otherwise they would have changed it or they think it is good as it is then they will never change that and we are at the same bad end.
Even if you could tell me why it is nonsense: it is nonsense. And there is no chance for the users to get in a better situation. Why it is? Not from interest. It is. That is the thing. Not why. That is their stuff to do.
True I donāt know why it is so. But I know that it is so. That makes one difference: I know exactly that and it shows me that there are tons of issues.
Azuls Falcon is using a new technology for GC. It is not made for normal Java use but for huge projects with a big amount of time for gc. It is really special but not that performant for small projects. I have tested it wide before releasing. Not a good Idea for small projects but a goos Idea for big projects where the Java original GC makes problems. It is then the fastest Java worldwide. But only then.
There are developments for AOT Compilers. Many developments. I would think about that. And none of them could be realized until now in LLVM. But anyway, there is the need for new technologies and new approaches in the Java World. That is one of the needed Parts: Java is always in movement.
āFar Managerā works for meā¦ 
The CPU executes integer float and double math the SAME way as every other language that spits out machine code
The rest of the load store etc that goes on around that IS possibly the culprit
And thats a result of HOW the code goes from Xojo source to machine code and the various transforms
Something I can be quite certain you DO NOT have full information about
It absolutely makes ALL the difference as you cant know HOW the source code turned into LLVM IR and then machine code unless you did
This process is NEVER written to disk so unless you decompile & debug it in action you would not be able to fully analyze anything but the final resulting .o files
WHY it is nonsense matters
And THAT is where āthe compiler guyā could help - if they had one
ABSOLUTELY !
Knowing a product has defects in one thing
If its your car you take it to a mechanic - and he can figure out WHY it has defects and fix them
In Xojoās case weāre the car owners
We know it has defects
But the mechanic wont help
Thats all Iām saying
And its based on ā¦ LLVM
LLVM can be used to write compilers for many languages
It too is never at rest
Gawd I would love to have had async await for the IDE
That plus real threads would have been awesome for many things
I do not have any information how Xojo handles it until the compiler comes up and how Xojo handles the rest internally. But there are issues. math isā¦ compare it with C, C++, Lazarus and Rust.
<For the user: no difference I am sorry. So your knowledge makes no sense for the user. It makes even no sense for you if you canāt change anything with the knowledge.
And we are at the point again: for the users are no differences in it. You may know the internals but you canāt change anything with that knowledge. So this knowledge acts like not available while it has no chance for changes.
There is a big difference in it. The mechanic repairs something what was working before. But in case of Xojo he would have to repair something what never worked properly. That is a big difference. Mechanics can do small changes if the vendor lets say GM gives spare parts. But they canāt change the entire engine, the electronics, the gear, the windowā¦while they would have to build at the end a new car and that they canāt. Thatās the Job of GM. The vendor. Xojo is the vendor of the Xojo IDE and Language and Framework and Compiler. they have to bring it in a running condition.
Sorry it is not BASED on LLVM. LLVM is used for parts. it has still a JVM inside and compiles a few parts of the code for faster startup and for slower amount of remote waitings. That is a big difference in my eyes. IT IS JAVA JVM based still. I know that Code and the structure behind really good. Trust me: it is not a LLVM running product. LLVM is used for the compiled code. Not for the Hit Code itself.
LLVM can be used. But it is always also a question of handling the LLVM and lookout for the right using of it. Wiriting for example Software with LLVM can be productive. A compiler dedicated for one platform can be the better solution. LLVM is not the only one.
The entire problem is: they need it and they need Threading and they realized it. Geoff Perlman by self wrote about it. But he thought people will shoot in their knees with Threading and decided: will not come. Async will also not come from the same reason. Hey what shall I say: Dead END
Oh dont misunderstand me - there ARE issues in the compiler but I dont thinks its at the level you believe it is
integers doubles floats and most numeric types, except currency, are the same in Xojo as any other language that uses IEEE formats which most CPUās use
Yes I cant change it for users of Xojo at this time
Xojo could IF they had the right compiler guy
Will they ?
Unlikely
Never say never 
Itās an analogy. Analogies are definitely not precise matches.
Bad choice of words
It USES LLVM for part of its tooling
Now while you CAN use LLVM as something like Javas JVM thats NOT how Xojo, or many others, use it
Xojo uses it as the compiler creation toolkit it is
To build a compiler and much of the back end + code emitters
However thereās still a lot of custom code before that to get to the LLVM IR
Iām quite sure many issues are in that stage from source text before the LLVM IR
Can be if you have the time & team to write all the IR generation, optimization, etc
Few do
LLVM gives you a lot of that just by using it
Which for a small team is a big win
But there is a big difference in the results all benchmarks generating with Xojo and C++ or Lazarus or Delphi. Why?
If they are uninterested in it the knowledge about the issues is worthless while nothing will be changed from it. the knowledge about the issue results is needed to know where the Xojo toolchain makes problems. Why it is so is not so important.
Again. The JVM is not in any way running with LLVM. Parts of the code will be compiled. The rest runs on JVM. Still. That is not what you wrote.
I agree in your view of many issues in the code before LLVM.
It is a big win only if the small team can handle it correct. That is here not the case as far as I can see.
Because your measuring MORE than JUST the integer computations etc
its all the baggage around it as well
Thereās a vast difference between being disinterested in the problem and knowing how to fix it correct it or having the right people to do that work
I truly have NO idea if they are, or are not, interested
And no way to know
But, from here, their actions say they are unable to do anything about it at this time - maybe ever
I dont know
None of us do
I have no idea why it doesnt have higher priority
Even when I worked there it was always a long discussion about what things should / should not have priority
M personal feeling was CRAHES & BUGS take first priority
But I didnt set the priorities and only got to put my 2 cents in along with everyone else
Again we have no idea about their interest
We CAN say that weāve seen no obvious signs they ARE interested or doing anything about it
Lets just say āBest laid pans of mice and menā
They had a compiler guy with a plan to address this but now they dont
I believe some of it has to do with method handling. I have been able using pragmas and Ptrs to get Xojo math code to match the speed of C code. I am not a C guy, so Iāll be the first to admit that my C code at the time could probably have been optimized.
However it became moot when I could just dispatch core soaking threads from C and decimate Xojos single core limitation. 8 Core system completed the task in 1/7th of the time that the Xojo app could do. Now I have a 12 core Macā¦ It gets even more silly.
The ONLY advantage to not being able to throw more cores at it, is thinking outside of the box, how can I do this more efficiently? Right now, Iām designing a function to collate 64,000 time based events, without using brute force as it takes 5 mins on a M2 Pro (Xojo made, so single core only).
I also started inlining some of my code (Macros would really help, but Geoff doesnāt understand them) and thatās why youāll notice almost all of the declares in OAK are external methods. By avoiding methods, that drastically improved operation time of my app.
Iāll admit that I donāt have the insider knowledge, just what I have observed.
Edit: It is C code, not C++ code!
Personally, I think thatās just an excuse to dismiss it. He says things like, we wonāt add that because itās only for target X, then something specific for target Y gets added. They wonāt add support for NSUserDefaults on the Mac, yet on Windows thereās the Registry. They wonāt add support for menubaritems on the Mac, yet on Windows, they have the tray itemā¦
I think the only time heās honest is when heās backed into a corner and says something like, āitās not worth our time to add that for youā. This may be true, but to say it someoneās face shows exactly how he values feature requests, and customers.
IMHO, itās been about money for a long time. Rather the lack of it.
Xojo has all the hallmarks of a has-been player where the owners are just cynically milking it for the last farthing before shutting it down.
The alternative explanation is that they are that clueless and think they are building for a viable future. One of my clientās clients was like that ā¦ just in a chat with the CEO about that now. They are still running Sql Server 2000 internally and the sample reports on their web site are from 2010. And they are still holding out for a buyer to take them on at 10x normal market valuations. So clearly delusional.