@inwinterhesleeps said:
It is really disappointing to hear what I suspected long ago... that the VSL programmers are biased towards Windows. That benchmark link really is just so silly, I expect more form VSL. I would bet that none of those programs get as much attention and expertise on the Mac side as they do for the Windows side, and who knows what kind of clunky workarounds they implemented to get that software that was developed on PC to work on Mac OS. Perhaps none, perhaps several, but we don't really know do we?
I am simply stating reality here - that most (all?) x-platform software performs better on Windows than on Mac. We (and others) use x-platform frameworks to be able to deliver software for both platforms. It is true that some (I believe all?) of these frameworks perform better on Windows than on Mac, which is one of the main reasons software appear snappier on Windows. To completely throw away the code and keep two separate branches of code for Mac and Windows separately, is just not a real solution for a small software company. It would be way too costly, and would take too much time.
Then you have the issue with the constantly changing "rules" for the Mac platform. First, there was PPC and Carbon. Then there was a sudden switch to x86, and Cocoa was added to the palette. Then we were told Carbon would not go to 64-bit. So the story continues...
Most of the specific platform efforts from our side actually go towards solving issues on the Mac platform. A big reason for this is the wide variety of combinations possible on Mac, compared to Windows. On Windows, you have x86 and x64, Win32 gui and VST 2/3 format. (With the very rare occasional Win/RTAS user). On Mac, you have 4 architectures - x86, x64, ppc, ppc64. Add to this AU, RTAS, VST2, VST3 formats, some supporting Carbon views only, some supporting Cocoa views only, some supporting both. Since we are not developing every piece of code on our own - we rely on 3rd party frameworks for a variety of things - we are also relying on these frameworks to implement support for whatever radical change Apple decides to push through at the moment.
The Apple shift to Cocoa-only for 64-bit operation, was probably the toughest one for most developers. Cocoa comes with some benefits (Carbon is terrible and badly documented), but also a lot of drawbacks. Large Cocoa apps using lots of widgets, which is exactly what audio apps are doing, tend to get slow, simply due to how the Cocoa framework works. I remember Apple recommending to keep Widget count to below 100 with Cocoa apps, something which is just not possible for a modern audio app. You could easily notice the decrease in responsiveness when Logic switched from Carbon to Cocoa, I believe in Logic v8. Somhow everything got "sticky" in mouse/keyboard interaction with the gui.
There are many, many other core technologies that also simply work faster on Windows than on Mac, due to the way the kernel, OS, SDK, compiler tools etc are put together. For certain things there are workarounds to be found, sometimes there are not. We at least are doing everything within our powers to make it better.