That creates a 1GB RAM disk; adjust the number of blocks (the 2097152 bit) up or down as desired.
I will say in my very brief test compile it didn’t seem to make much difference. I didn’t time it with a stopwatch, but there’s little noticeable difference in compile times whether the debug folder is on the RAM disk, my system SSD, or an internal 7200rpm hard drive. That’s with a medium-sized project; a larger project might be different.
Even creating a 4 GB RAM disk and copying all of Xojo, plus the project files, and the debug output folder to that ram disk made very little noticeable difference.
Okay, I did some stopwatch tests. With everything Xojo-related (except for temp files and whatever else Xojo might stash in, say, Application Support) on a RAM disk, it takes ~6.1 seconds to compile my current project, a small-to-middling application. Compiling it with everything on SSD takes ~6.2 seconds. Essentially the same. I mean, 0.1 seconds is within the margin of error of me tapping my finger to start and stop the timer.
I think the main factor is that I have plenty of excess RAM in my computer, so probably everything Xojo-related is already cached in memory by the OS. Running a RAM disk is thus pretty much pointless. It would seemingly be somewhat faster for writes during the build, but I think most debug builds are incremental and don’t necessarily do a lot of writing, i.e., overwriting (Xojo engineers could weigh in here).
I noted (without timing it with a stopwatch) that launching the IDE or loading a project doesn’t seem one iota faster with everything Xojo-related on a RAM disk than it does loading everything from SSD, which only makes sense if the OS is not actually loading it from SSD but rather from its file cache. I suppose I could purge my disk cache and measure things, but I don’t care that much.
Basically, a RAM disk is redundant. If you have enough free memory to set up a RAM disk, you have enough free memory that your build data will already be mostly cached in RAM by the OS. I believe that means the solution is, “Buy more RAM.”
Greg, if you could provide me with the locations of where the intermediates are created and where it will build the actual executable, I’ll have a play around. If you want to, you can DM me this information and I’ll sign any confidentiality agreement you desire.
Yeah a minute may be minuscule to you, but when you’re trying to track down an application crash, which is already frustrating enough, having to wait whatever time it takes to compile, launch app, load data set, being running test, crash. Apply fix trial #73, rinse and repeat.
I suspect that Xojo probably does it’s intermediate builds and final assembles in the temp folder. Which is why I’d like to get the official information as to where this is done before running such a test. Once I have that I can experiment with trying to trick Xojo in using a RAM disk for this purpose.
And this is of course working on the theory that the bottleneck is APFS on an older SSD. It might be a whole range of things; but if there’s some thing I can do that will improve my compile time significantly, I’ll take it. If this works, it’ll be great also in that I’m no longer using a SSD write to debug my apps. which should make my SSD last longer! lol… 8 years is already pretty darn amazing!
That’s a great conclusion, the only problem is Apple’s current thinking is that to buy more RAM, you need to buy a whole new computer!
[quote=466496:@Sam Rowlands]
That’s a great conclusion, the only problem is Apple’s current thinking is that to buy more RAM, you need to buy a whole new computer![/quote]
That is why i buy 27" iMacs! (that and the fact I do very little traveling of course)
I am interested in how this works out.
I have a lot of RAM on my machine and the SSD is formatted APFS. I don’t have such large projects but the cumulative debugging/testing time saved could be significant over the long run! If this requires Xojo letting us have a preference for where it writes temp files during the process, I hope they do so!
You’re right. In the temp folder (opened by using “open $TMPDIR” in Terminal) there’s a “xojo scratch #####” folder containing .o and other intermediate files for whatever application you’re building. The temp folder also contains a bajillion dylibs from the MBS plugins.
I have no idea how to change the location where Xojo writes those files; I’m guessing it’s probably something only Xojo can do.
But I don’t know how volatile those files are anyway. I’m 99% sure most of them wouldn’t change from one compile to the next. I assume that means they would also be in memory already, in the OS file cache.
That explains why my iMac with 32 GB of RAM is so much faster than the MacBook Air with 8 GB RAM. The Fusion drive on the iMac has only 50% of the speed of the SSD in the Air.
Right;
So I’ve sifted through the colossal amount of data generated by fs_usage Xojo -f filesys and can now say that it appears Xojo only takes 5 seconds to build my application on the disk. I’m guessing that’s happening at the end of the first 20 seconds.
I would also like to say that I am impressed with it only taking 5 seconds. I assume that if I remove the file icons from Xojo, I can make this a tiny bit faster as they don’t appear to be cached, so it seems like they’re created every time I “Run”. But it appears I am not going to gain much improvement here. I would imagine that a faster CPU would reduce that initial 15 seconds.
The last 20 seconds Xojo isn’t doing anything disk related. Which then leads me to investigate my own build scripts.
[quote=466508:@Norman Palardy]in Terminal
There’s a “xojo scratch #####” folder
The ##### is the PID of the instance of Xojo that is running[/quote]
Thanks Norman, I now have the two locations that Xojo uses when building the application, as well as the path to built application, so there’s 3 folders in total.
I’m going to turn my attention to investigating my build scripts as I suspect the last 20 seconds are to do with editing the plist, preparing for code signing and then the actual code signing.
Which gives me hope, because that it something which I’m (sorta) in control of.