But it’s summer where you are 
Your one liner made me actually notice for the first time that you’re from South Africa. Just never noticed it before.
Yip, born and bred in Africa 
Back to the exe foot size on hard disk.
I have an AppleScript script saved as application whose size is 106,732Bytes.
It allows me to select a text file in the frontmost Finder folder and create there one folder / one line.
What will be the Xojo (4.1) app size to do that (in MB) ?
What can be the app size when Xojo will use LLVM ?
That is the reason why I use AppleScript for basic things (usually text file manipulations, folder creating batchs, etc.) instead of Xojo *.
Note that I recently had to move 4 AppleScripts to Xojo (write them entirely in Xojo) because they were slow as hell (simply to rename around 5,000 files in a folder tooks around the afternoon:
a text file with two entries(current file name \tab new file name)
and in a loop, change the file names using the above text file contents
- And I will add one because of the troubles I had with the end of line character
under AppleScript (I have a solution to remove that trouble in Xojo).
The solution name is ReplaceLineEndings
Reducing binary size isn’t the goal of using LLVM as the compiler backend. The specific goals, in rough order of importance, are:
- supporting the x86-64, ARM, and ARMv8 (64-bit ARM) architectures
- improving execution speed / code quality
- reducing the amount of code we have to maintain in-house, enabling us to focus on other bugs or features
And to put a damper on any extremely unrealistic expectations about performance: it won’t be as fast as C, much less FORTRAN. There’s a bunch of reasons for this, but a good chunk of it boils down to Xojo being a “safer” language that has more features. For example, there’s introspection, exceptions, bounds checking, cooperative threading, and stack overflow checking.
It will, however, be much faster than the current compiler. We’ve literally seen a 15x speed improvement with XojoScript, though admittedly one that was extremely heavy on floating point and other mathematical operations. Operations dealing with databases, file i/o won’t see much improvement since the bottlenecks aren’t in the compiled code.
Joe:
thank you for your kind answer.
I do not say how many (hundreds) small scripts (AppleScripts) I have in my hard disks. If I create Xojo applications for each one
But I can (and I do) put more than one script in a Xojo application to leverage the HD foot print.
BTW: file i/o is fast enough here for daily operations. For the database import/exports: these operations takes time and have to be done when time is not critical, so if the time is shorter: OK, else: OK too. I usually do something else when a long (in time) operation is running. *
Xojo will be faster when it will use LLVM: good ! But do not wait after me to get the % of speed ;-:). To know it is faster and watch it is good for me.
- I power on my computer first and I remove my coat afterwards (while the boot is “doing its stuff”. Doing so will avoid a wait.