On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin <e...@chromium.org> wrote:
> General comments: Linux tends to be "lighter" which means it does
> better on older hardware, so depending on what sorts of laptops you're
> talking about that could be a major factor. Windowses later than 2000
> or so need surprising amounts of hardware to run well. (I don't
> mention Mac below because there hasn't been much performance work
> there yet.)
I pulled out the laptops side-by-side to be more scientific about
this. Here are the stats:
XP: 2GB RAM, Core2 Duo, 2.00 GHz
Ubuntu 9.10: 2GB RAM, Core 2 Duo, 2.40 GHz
So, the Linux machine as 20% more CPU to work with.
>> 1) Scroll performance is extremely good. Even on Gmail, I can only
>> get the mouse to lead the scroll bar by a dozen pixels. On Slashdot,
>> it doesn't even look like I can do that.
>
> On "plain" pages (one scrollbar on the right, no Flash) scrolling is
> literally shifting the pixels down. On Linux we do this by sending a
> command to the X server, which is a single process that even has the
> graphics drivers built in so it talks directly to your graphics card
> and can in theory do a hardware-accelerated copy. I would expect this
> to be pretty fast.
Looking at this more carefully, scroll performance on Slashdot is
great in both Windows and Linux. On Gmail (no chat mole), there's a
noticeable difference. Here's a visualization of the numb on the
scroll bar:
||
||
||
||
||
||
-- <-- Click here and pull down
--
-- <-- Linux: mouse latency gets to here
||
|| <-- Windows: mouse latency gets to here
||
||
||
||
Admittedly, it's hard to see precisely, but it affects the "feel."
Scroll on Windows feels slightly heavier.
>> 2) Tab creation is very fast. Maybe the zygote is helping here? Can
>> we pre-render the NTP on other platforms?
>
> The zygote is paused right at process start, before we've even started
> a renderer. On the other hand Windows process creation is more
> expensive.
>
> There is a "new tab" graph that attempts to measure this. The various
> lines on the graph are tracking how quickly we get to each stage in
> constructing the page. We hit the first line 20ms faster on Linux
> than Windows likely due to the zygote and "slow" Windows process
> creation, but process startup seems to be a relatively small part of
> the total time. Linux hits other lines later and Linux and Windows
> hit the finish line at around the same time.
So, I retried this with a fresh profile on both. The differences are
not as dramatic as I remember. I can't actually see a difference when
I run them side-by-side.
>> 3) Startup time is faster than calculator.
>
> I'm not sure if you're kidding. Do you mean Windows calculator?
I meant Linux calculator.
> In the limit, I'd expect us to pay a lot more on Linux due to using
> more libraries, GTK initialization, round trips to the X server, etc.
> but I don't know much about Windows here.
I tried turning on the GTK theme. That killed startup performance.
Side-by-side startup easily noticeably faster in Linux. To be more
precise, drawing the first pixel is noticeably faster. Total startup
time is harder to say.
Interestingly startup drawing is different between Windows and Linux.
We might want to film with a high-speed camera to see exactly what's
going on, but here are my impressions:
Linux draw order:
1) Fill entire window with blue (This looks bad, can we use a
different color? White?).
2) Paint main UI widgets, including NTP.
3) Paint NTP thumbnails.
I bet that (2) is actually broken in to two pieces, I just can't see it.
Window draw order:
1) Paint NC region (the blue border around the edge).
2) Paint main UI widgets (without omnibox).
3) Blit NTP content area (the sweep from top to bottom is noticeable).
4) Paint omnibox.
5) Paint NTP thumbnails.
Keep in mind that this all happens very fast, so I could be imagining things.
Ideas for improving perceived windows startup time:
1) Draw a fake omnibox with the rest of the main UI widgets.
Currently we draw the omnibox really late and it looks slow and bad.
You can see this if you have a dark desktop wallpaper and you focus on
where the omnibox will be. You'll see a dark rectangle inside the
main toolbar which is the desktop showing through. We should never
show a dark rectangle there.
2) Fill the main content area with white when drawing the main UI
widgets. You can see this if you focus on the bottom of where the
bookmark bar is going to be (especially when the bookmark bar is set
to show only on the NTP). You'll see an edge there when the bookmark
bar is draw by while the main content area is still transparent.
There's no reason we should ever paint an edge there.
I bet the reason Windows startup feels slower is whatever drawing
operation we're using for the main content area is slow. The
top-to-bottom sweep probably makes me feel like the browser isn't
loaded until the sweep reaches the bottom, whereas I feel like Linux
is done earlier in its startup sequence.
Adam
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
