If anyone needs a test page, you can log in as my test user
styoung.tra...@gmail.com (pwd:browsertest). Then go to
https://www.facebook.com/styoung.
you could maintain a separate document for measuring items, so you could
measure without reflowing the main document.
We are actually already
On Feb 14, 2012, at 10:25 AM, Steven Young wrote:
(2) 50% of time spent painting images... This is a simple speed vs quality
tradeoff. If you down-sampled the images on the server, they'd download
and paint much faster.
Thanks. Downsampling sounds like a straightforward solution. We
If anyone needs a test page, you can log in as my test user
styoung.tra...@gmail.com (pwd:browsertest). Then go to
https://www.facebook.com/styoung.
Nice!
I took a trace of this timeline and saw similar results as before (lots of time
computing .offsetHeight and .scrollLeft), but with less
It's hard for me to advice you on how to optimize your website but will you
be interested in creating a reduced test cases where WebKit is slow?
I'm sure we can (at least try to) resolve your pain points if you can
create benchmarks licensed under BSD/LGPL or WebKit performance tests (see
Hi Steve.
Do you have a test account with a fixed content set that we can use for
profiling?
It's hard to speculate about performance issues without profiling, and we might
get confused if we all profile different content.
Thanks,
Geoff
___
Profiling scrolling through my own timeline, and focusing on points where the
CPU hit 100% or greater, I saw this:
(1) 50% of time spent in style calculation forced by accessing
element.offsetHeight in JavaScript.
We then have JS which checks the heights of all the
stories on in the
Not sure what tools you have used but you may find this helpful:
http://code.google.com/webtoolkit/speedtracer/
On Sat, Feb 11, 2012 at 10:02 PM, Steven Young styoung.bi...@gmail.comwrote:
[cross posting from mozilla's dev lists]
I'm on the Timeline team at Facebook, which is going to be the
will you be interested in creating a reduced test cases where WebKit is slow?
Ryosuke - For now, user complaints about slowness are too
unpredictable and poorly defined for me to create a simple test case.
I will report back here if we reach that point.
(1) 50% of time spent in style
(1) 50% of time spent in style calculation forced by accessing
element.offsetHeight in JavaScript.
Geoff - I am going to bite the bullet and rip this logic out. We are
pushing too much complexity into the browser.
Bear in mind that I didn't do enough analysis to explain why the
[cross posting from mozilla's dev lists]
I'm on the Timeline team at Facebook, which is going to be the new
format for everyone's profiles real soon now.
https://www.facebook.com/about/timeline We'd like to improve its
browser performance, so I'd appreciate any suggestions for things we
should
10 matches
Mail list logo
