Followup To The Myth Of Cocoa Apps
A while back I took Paul Stamatiou (and by proxy, VMWare) to task about their claim that Cocoa makes them so much more efficient. My take was that it was a Cocoa vs Carbon argument and VMWare employees came rushing to explain that it was actually a Cocoa vs Qt argument. Kudos to them for being in touch enough to join the debate, I had to log a support case with Parallels to get their side. Unfortunately, the point stands that users shouldn't care what framework an application is used in - I certainly had no idea Parallels used Qt.
I'm late in posting the follow up but I thought it was worth providing a quick follow up. Here's what Matt Ginzton had to say in an email to me (see the comments from the previous post for me detail):
Just saw your "myth of cocoa apps" post. While your overriding argument (Cocoa doesn't automatically make you awesome) is of course correct, building this argument around VMware Fusion is somewhat off topic — the reason we draw any attention to our Cocoaness is to make the point that we're using
native Mac technologies, and not at all a point about *which* native Mac technology.Boiled down: It's a point about Cocoa vs Qt, not Cocoa vs Carbon.
Ben Gertzfield (who by the way is the Fusion lead developer) jumped in at comment 6 to point this out. As I understand it, Parallels' use of Qt is actually a significant resource drain (as you correctly say in comment 10, this doesn't relate to the core virtualization itself, but beyond the core virtualization these apps do put a lot of Mac OS UI onscreen, especially in Unity/Coherence modes, and I believe your conclusion in comment 10 — "I doubt that Qt is really making that much difference to Parallels because of precisely that but I could be wrong" — is indeed incorrect).
And beyond the resource drain issues, it's also hard to get truly native look and feel from a crossplatform UI tookit.
And when I contacted Parallels, they had this to say (including my original email):
The recent VMWare press releases touted their Fusion product as being developed from the ground up using Mac OS X native technologies and a
number of VMWare employees have claimed that Parallel's use of Qt adds a significant perforance hit, particularly in Coherence mode (in the comments of http://www.symphonious.net/2007/08/07/the-myth-of-cocoa-apps/).This claim seems suspect given the very small amount of UI components that are displayed in a virtualization engine - do you have any benchmarks or an official response to these claims?
Regards,
Adrian Sutton
Hello Adrian,
Actually, the opposite is true! We use QT and it makes highly optimized native Carbon calls for guest screen redrawing in both Coherence and OS Window modes and we use QT only for non time-critical GUI operations– like dialog boxes. In several independent tests performed by our users, and Fusion users, its been found and widely discussed that our overall GUI performance is faster than VMware Fusion's, just take a look at what users say on video performance on ours and VMware forums.
–
Best regards,
Robert
My interpretation is that VMWare are just guessing at the performance characteristics of their competitor and letting their marketing department mislead potential customers based on that. That said, Parallels really need to learn about blog search engines and stay on top of these conversations. It's also a shame that they couldn't provide even a vague reference to actual profiling data when asked for it - how hard would it be for an engineer to look at the latest profile data and give a rough guide to how much time is actually spent in the QT libraries. That data would have proven VMWare's claims wrong outright, instead it's still up in the air as to whose right. My impression is that VMWare is less likely to understand the performance characteristics of Parallels than Parallels themselves.
As for looking more Mac like - the VMWare toolbar is nice and Cocoa like whereas the Parallels one is on the side and very much a custom job, but Parallels takes up less space and does the job just as well. Perhaps I'd care more if it weren't for the fact that I never run in Windowed mode so I almost never see it anyway.
Unless someone can produce solid figures I'm going to call it a draw. VMWare are more involved in the discussion and seem to care a lot more about their products so they're likely to provide better customer service, but I wouldn't trust their marketing claims without verifying them for myself. I stand by my original claim that the framework shouldn't matter and in this case I'm more convinced than ever that it doesn't.
August 29th, 2007 at 11:03 am
> My interpretation is that VMWare are just guessing at the performance characteristics of their competitor
Given how Fusion trounces Parallels in benchmarks (http://www.macnn.com/articles/07/08/16/fusion.vs.parallels/), I don’t think VMWare is just guessing…
> Parallels really need to learn about blog search engines and stay on top of these conversations.
Do you think that thread on your blog was that interesting that the world should stop and comment on it? By continuing to talk about this insignificant issue, you certainly seem like somebody with too much time in his hands.
August 29th, 2007 at 11:18 am
Whether or not Fusion is faster than Parallels doesn’t affect what they know about *why* Parallels performs the way it does. The Fusion team seemed to care enough to pay attention to that thread on my blog as did thousands of other people, so it would seem important enough for people to comment on.
I’d also appreciate it if we could steer away from insults and stick to civil discussion.
August 29th, 2007 at 5:10 pm
Hi Adrian,
I’ve personally profiled the OpenGL calls that Parallels’ Qt functions end up using to render the SVGA framebuffer of a virtual machine, and they’re slower than the native OpenGL calls VMware Fusion uses.
In addition, take a look at the WindowServer process before and after starting Parallels and booting a virtual machine. You’ll see it’s a pretty hefty drain; Qt creates literally hundreds of hidden windows whenever you use it on Mac OS (this is not a Parallels issue; it’s a Qt issue) and it causes the Quartz window server to gobble up memory like crazy.
Now, this isn’t to say that Qt can’t be as fast as OpenGL and Cocoa. It can. But, like any multiplatform toolkit, that’s not its forte; it’s good at making UIs quickly portable to dozens of platforms with a semi-native UI, which is why Parallels uses it.
August 29th, 2007 at 5:52 pm
Ben,
Good to hear someone doing some actual profiling, but what actually matters here isn’t the underlying calls - it’s Parallels itself. If 99% of the time Parallels is handling memory translation for the guest OS, nothing you do in the GUI will impact performance. You need to look at the overall picture to get the real answer.
That said, this is the closest to actual data we’ve seen so far so thank you. I would ask though, how did you determine which OpenGL calls Parallels is using? Would it be possible for their code to have specifically optimized sections such that they make better use of OpenGL or otherwise change the performance?