This is a blog article to remind everyone writing application in C to no longer use FSCreateFileUnicode function because it is very slow on APFS in our tests.
Speed tests show a 50 times slower result with APFS and FSCreateFileUnicode function:
Time needed for NSData writeToURL: 0.350506
Time needed for fopen & fwrite: 0.218125
Time needed for FSCreateFileUnicode: 11.721211
each for 1000 files to be created & written in a Xcode project.
For creating the file (not opening and writing!), you get a 11 second wait for 1000 files. Using fopen, the standard C library, you get a much better performance.
For Xojo, it looks like they use FSCreateFileUnicode for TextOutputStream and BinaryStream classes. We got one project run in 5 minutes instead of 2h by just changing the code to write output files. This tool writes something like 100000 files in a run and heavily benefits from any optimization. Reported as feedback case 54276.
By the way our LargeBinaryStreamMBS class in MBS Xojo Util Plugin still uses the old APIs, too. We need it mainly to read/write resource forks on Mac, but as that is going away, it may be good to deprecate that in favor of an optimized BinaryStream from Xojo in a future release?
The problem seems in Apple's implementation to emulate older and deprecated FSCreateFileUnicode with the newer Apple File System. For years they told us to move away from FSRef and really it is time to move. I also reported this to Apple (case 46302303) to let them know that it's slow than they can help to keep old applications performance well by improving it.