Cocoa widget Tp numbers

[jos...@gmail.com]

We have been looking to turn on Cocoa widgets on the trunk for a while
now, but have been held up primarily by Tp numbers. Currently Cocoa
widget Tp is 12-13% higher than Carbon Tp.

Over the past 6 weeks or so I have been looking into this problem. I
have found that 4-5% of the Tp problem comes from the fact that
NSQuickdrawView, our basic view object in Cocoa widgets, cannot be made
opaque (OS/Framework issue). This problem will go away when we stop
using Quickdraw - when we turn on Cairo on Mac OS X.

That leaves a 7-8% hit in Tp which is unexplained. I have done some
profiling of our drawing code and I don't see anything out of the
ordinary. I have done other types of tests to try to determine if we
are drawing too often or our invalidation isn't working correctly, and
I don't see any problems in those areas. I believe the unexplained 7-8%
is inherent to using NSQuickdrawView (issues other than opacity), the
Cocoa frameworks, and Objective-C. It is hard to be more specific
because Cocoa functions don't match up with Carbon functions very often
and are thus hard to compare.

There probably isn't a bug or two in cocoa widgets that is responsible
for the unexplained part of the Tp hit, and I think finding something
meaningful to blame it on is going to be very hard. It is probably the
result of a bunch of issues inherent to the Mac OS X technologies we
are using. I don't think there is anything in the Cocoa widget code
that we're keeping on after the Cairo transition that is slowing us
down much. Cairo-Cocoa has a lot of potential, and the sooner we start
working on performance there the better. I am confident that we can get
performance where we need it to be. Many people are well aware of this
issue, it is not going to slip through the cracks and leave us with
unacceptable performance.

(If you don't look at this issue in the regression sense, performance
is already quite acceptable - Camino has been using this code for years
now and is considered by many to be one of the fastest browsers on Mac
OS X. However, regressions should not be taken lightly, we cannot just
consider the issue in this light.)

How do people feel about the issue of turning on Cocoa widgets on the
trunk? Anyone have any ideas for performance improvements that we might
be able to realize in the near future? Other thoughts? This is a
high-priority issue since we really need to move forward with Mac OS X
on the trunk, and that means resolving the Tp issue or moving ahead
with an awareness of it.

[stu...@gmail.com]

jos...@gmail.com wrote lots of stuff
> cocoa widget Tp is 12-13% higher than Carbon Tp.

According to tinderbox cocoa is faster by 4ms.

[stu...@gmail.com]

On my machine, I see some pages being about 6-7% slower while some are
a about 3-4% faster. If I make views opaque that does seem to make
things a bit faster (3%) or so. I've got a few profiles I'm looking at
trying to find a few more percent, but with tinderbox showing +/- 4ms
I'm not sure how much better we are going to get by making widget level
changes.

I'm going to do some no-text builds with qd, cocoa and cocoa-cairo to
see what the effect of cocoa vs cocoa-cairo is (in theory we might be
faster with cairo w/o text).

stuart

[Håkan Waara]

Isn't the fact that Cocoa widgets is creating one new ChildView
(NSView) + corresponding nsChildView per nsIWidget slowing us down? As
far as I know, all other platforms only have one nsIWidget, that
correspond to the top-level window.

/Håkan

[stu...@gmail.com]

Håkan Waara wrote:
> Isn't the fact that Cocoa widgets is creating one new ChildView
> (NSView) + corresponding nsChildView per nsIWidget slowing us down? As
> far as I know, all other platforms only have one nsIWidget, that
> correspond to the top-level window.
>
> /Håkan

No, we create toplevel windows with child windows on all platforms.
Mac QD was the only platform without "real" child windows.

[Håkan Waara]

Are we still talking about iframes, etc? From how I understand it,
win32 doesn't have a separate native view for every nsIView, like cocoa
does.

/Håkan

[Boris Zbarsky]

Håkan Waara wrote:
> Are we still talking about iframes, etc? From how I understand it,
> win32 doesn't have a separate native view for every nsIView, like cocoa
> does.

Er.... There's nothing native attached to every nsIView, I hope! There should
be native things attached to nsIWidgets...

-Boris

[stu...@gmail.com]

What boris said.

Some views have widgets some don't.

stuart

[stu...@gmail.com]

stu...@gmail.com wrote:
> I'm going to do some no-text builds with qd, cocoa and cocoa-cairo to
> see what the effect of cocoa vs cocoa-cairo is (in theory we might be
> faster with cairo w/o text).
>
> stuart
>

I went ahead and got these numbers but the cocoa vs cocoa-cairo numbers
don't seem to be entirely text related. Vlad thinks some of the image
drawing code also needs to be improved.

There is still a couple % slowdown that I'm seeing on my local machine
that doesn't show up on Tinderbox and that I'm having a hard time
finding the exact cause of. I don't think we should block on it. Lets
keep the non-cocoa-non-cairo build going on the Firefox-Cairo page so
we can keep an eye on its numbers as we move to cocoa and then to
cocoa-cairo to make sure that we stay as fast along the way.

stuart