I’m just curious about the LLVM compiler What is to be gained by switching to it?
Performance for one thing. RBScript uses LLVM, and I imagine XojoScript does as well. Last I tested it RBScript ran circles around native code on compute / loop intensive tasks when all the optimizations were on.
That doesn’t mean all code will experience the same or even any speed boost. But I would guess that LLVM will make a noticeable difference.
There are several advantages. For one, LLVM does dead stripping, that is it doesn’t include parts of a program that are never used in the built executable. The current Xojo compiler doesn’t do this, which is one of the reasons that Xojo-produced executables tend to be rather large. A related advantage is that LLVM is an optimizing compiler whereas the current compiler is not. LLVM also supports several different CPU architectures (e.g. ARM) which would make adding mobile app support much easier/quicker.
I would also imagine that there is a huge win by using LLVM because there is now a lot of compiler code that does not need to be written or maintained by the Xojo team.
I thought the current compiler did do some code stripping.
[quote=14937:@Andrew Lambert]There are several advantages. For one, LLVM does dead stripping, that is it doesn’t include parts of a program that are never used in the built executable. The current Xojo compiler doesn’t do this,
[/quote]
It does just not at the same level of granularity
It can strip classes or modules if they are not used - LLVM may allow us to strip at a much finer level - say the method level
- linkers, better exception handling and a PILE of other optimizations in code
And we get a lot of very useful stuff from NOT having to write the entire compiler since lots of others are contributing see The LLVM Compiler Infrastructure Project
There’s STILL lots of work for us to use it though
It’s late and the big things have been mentioned already, so I’ll leave you with a fun and unrelated fact: about 30% of the IDE binary’s size is checking for nil objects.
In previous discussions I’ve heard that LLVM enables Xojo to return to single EXE File Distribution on Windows without any linked Libs in DLLs, right?
Well, one problem remains and that is optimization in the way the Xojo frontend generates the intermediate code for LLVM. If the nil checks are inlined well, the LLVM compiler may optimize away 90%.
It opens the possibility, but I don’t think that is the plan. At least, from what I’ve heard.
My tests using RBScript indicate that the LLVM compiler speeds up matrix operations and two-dimensional array access by factors of ~3. For those writing scientific applications, the LLVM compiler will provide a significant improvement in application speed.
In response to the discussion on single-file executables, on Monday, March 1, 2010, Geoff wrote on the blog
(see http://www.realsoftwareblog.com/2010/03/compiler-better-stronger-faster.html) the following.
“And for those that deploy on Windows and Linux, LLVM will eventually bring about the return of the single-file executable.”
So I am hoping this option is available as my Windows users complain about dealing with a library. Thus, I still compile many of my apps using RB 2007.4 to generate a single-file executable, and make that available to those who prefer it. Naturally, there are many features that must be removed to make that possible, but for some, it is worth it. We must all remember that our users have preferences that may or may not be logical.
If the horrible net framework that makes Visual Basic so awful is as awful as many of us think, having to drag along a library should also be viewed as awful. It is also unnecessary. Lets get rid of it!
Please don’t be too optimistic. LLVM is not magic or a solution for world hunger.
[quote=15051:@Robert Birge]In response to the discussion on single-file executables, on Monday, March 1, 2010, Geoff wrote on the blog
(see http://www.realsoftwareblog.com/2010/03/compiler-better-stronger-faster.html ) the following.[/quote]
This was on the roadmap at one point, but is no longer a priority. It poses several technical challenges, has security issues, and wouldn’t have delivered the end product users expected. One of the larger things we would lose is the ability to have crashes in RBGUIFramework.dll and such sent to us automatically by way of Windows Error Reporting.
[quote=15051:@Robert Birge] Thus, I still compile many of my apps using RB 2007.4 to generate a single-file executable, and make that available to those who prefer it.
[/quote]
To create a single-file executable on Windows. I’m using Enigma Virtual box. http://enigmaprotector.com/en/downloads.html
Thanks for that tip, just what I have been looking for. Info on the web-site looks neat, will try it out for sure. 
I tried Enigma, but a lot of my users started complaining that it triggered their
Anti-Virus programs. I finally had to remove it from my program.
[quote=15253:@George Balla]I tried Enigma, but a lot of my users started complaining that it triggered their
Anti-Virus programs. I finally had to remove it from my program.[/quote]
Could be interesting to know which anti-virus program they are using.
Under AVAST and MaCafee I don’t have any problems. But I don’t use the Registry tab folder.
I’m only using:
Field: Enter Input File Name // This is your compiled RS/Xojo executable.exe file
Field: Enter Output File Name //This is the new executable with all files included
Tab Folder Files: Add Folder Recursive And Add Files.
It’s not the latest version I have. Using Version Enigma Virtual Box 6.60
[quote=15253:@George Balla]I tried Enigma, but a lot of my users started complaining that it triggered their
Anti-Virus programs. I finally had to remove it from my program.[/quote]
Just tested “enigma virtual box” and “enigma protector”.
You are most likely referring to using the “Enigma Protector”, that software is capable of encrypting your executable which is flagged red by many anti-virus software due to their inability to decrypt the contents. Protectors which encrypts executable code like this are often used by people who want to hide back-doors and viruses.
If you are using the “Enigma Virtual Box” however, the content is not encrypted, just packed into a virtual container, and almost all anti-virus software are able to fully check it’s contents, and they report it’s “good”.
Here is a link to a test I did with the “Enigma Virtual Box”:
As you can see, the “Enigma Virtual Box” checks “clean” by 99% of all anti virus. Except from ONE, which is “eSafe”. eSafe may not have included a unpacker for the enigma file-format and instead just added a “quick and dirty” flagging of it instead (Which is of course “bad practice” from their side). I’m sure the “suspicious” flag done by eSafe in that test can be fixed by contacting the Enigma corp and notify them about this problem.
[quote=15253:@George Balla]I tried Enigma, but a lot of my users started complaining that it triggered their
Anti-Virus programs. I finally had to remove it from my program.[/quote]
Just another short addition, I went on a hunt for similar apps like Enigma Virtual Box, and found this:
I just packed a Xojo app with DLL’s successfully using the “BoxedApp Packer” free demo, and it came out 100% clean in all anti-virus tests using virustotal.com. So, might be worth looking at that one, but it is not free.
Some others I also found randomly while hunting (not tested):
http://molebox.com/
http://codeissue.com/issues/i34e25b3b24db61/can-i-merge-exe-and-dll-into-one-single-executable-file
And for even further hunting yourself:
https://www.google.com/search?q=combine+dll+and+exe+into+one+file