It should be noted that "about:objects" (which currently is really all about
the life-cycle of tasks) is currently only enabled by default in Debug
builds. If you want to enable it in your personal Release build, add a
line:
#define TRACK_ALL_TASK_OBJECTS
to src/base/tracked.h around line 24 (whe
On Mon, Aug 31, 2009 at 4:50 PM, John Grabowski wrote:
> jam: It's a good idea; we came to the same conclusion.
>
Good to hear :)
> I implemented the about:ipc UI as part of our performance focus last week.
> However, when I hooked it up, I noticed the logging itself was never fully
> ported f
jam: It's a good idea; we came to the same conclusion.
I implemented the about:ipc UI as part of our performance focus last week.
However, when I hooked it up, I noticed the logging itself was never fully
ported from Windows; it uses a cross-process waitable event, but
waitable_event_posix.cc isn'
I see similar jankiness on Windows. Someone is blocking the main thread.
Linus
On Mon, Aug 31, 2009 at 9:17 AM, Amanda Walker wrote:
> On Mon, Aug 31, 2009 at 12:12 PM, Mark Mentovai wrote:
>
>> HTTP resource loading shouldn't be on the browser's main thread. This
>> only applies to DOM UI re
On Mon, Aug 31, 2009 at 9:50 AM, Scott Hess wrote:
> It might be interesting to have the IO thread tag messages with the
> time as they go by, and have the UI thread keep track of the
> distribution of times that messages spend enqueued. Then we can set
> goals around how fast IPCs get pulled of
On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess wrote:
>
> On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote:
> > Well, that annoying throbber is still chewing up time, causing some
> > amount of UI loop contention while the images, thumbnails, and icons
> > are fetched. Windows and Linux don't h
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote:
> Well, that annoying throbber is still chewing up time, causing some
> amount of UI loop contention while the images, thumbnails, and icons
> are fetched. Windows and Linux don't have a throbber for the new tab
> page. We shouldn't either.
On Mon, Aug 31, 2009 at 9:10 AM, Evan Martin wrote:
> Another option is for the browser push these resources into the NTP as
> it's being constructed. That is, textually append a
Evan Martin wrote:
> The one that's easy to break is incognito: open one normal window, one
> incognito, try refreshing the NTP on both. Check that this actually
> works on trunk before you assume any breakage was introduced by you.
Yeah, I noticed while I was working on it that the system seems
On Mon, Aug 31, 2009 at 9:17 AM, Brett Wilson wrote:
> On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote:
>>
>> I spent a chunk of last week looking at the new tab page performance
>> on startup on the Mac. I found that the renderer was waiting on data
>> from the browser process for what seem
On Mon, Aug 31, 2009 at 9:17 AM, Mark Mentovai wrote:
> Evan Martin wrote:
>> This cache is in-memory only, right? That is, it's generated during startup?
>> (In the past I've talked about caches but I'm worried that the NTP
>> positioning will jump around due to stale caches, since the site
>> r
On Mon, Aug 31, 2009 at 12:12 PM, Mark Mentovai wrote:
> HTTP resource loading shouldn't be on the browser's main thread. This
> only applies to DOM UI resource loading, chrome: and chrome-internal:.
> That stuff gets funneled through the browser's main thread for things
> like profile and them
Evan Martin wrote:
> This cache is in-memory only, right? That is, it's generated during startup?
> (In the past I've talked about caches but I'm worried that the NTP
> positioning will jump around due to stale caches, since the site
> ranking is based on day granularity. Though that could be co
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote:
>
> I spent a chunk of last week looking at the new tab page performance
> on startup on the Mac. I found that the renderer was waiting on data
> from the browser process for what seemed like far too long. The key
> to this problem is that re
Amanda Walker wrote:
> Great writeup. There's definitely too much going on in the UI thread. Even
> after the page paints, I'm seeing multi-second pauses while additional stuff
> comes in, where the browser process is unresponsive (example: iGoogle with a
> bunch of gadgets). It's not clear to
One more thing: implementing the jankometer is relatively easy and
would help you track this down. See r20130.
On Mon, Aug 31, 2009 at 9:10 AM, Amanda Walker wrote:
> Great writeup. There's definitely too much going on in the UI thread. Even
> after the page paints, I'm seeing multi-second pau
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote:
> Since these tasks require profile and theme access, the approach is
> to build up the HTML and CSS early, on the UI thread where such access
> is permitted, and cache them. When a request for the HTML or CSS
> comes in, the browser can then
Great writeup. There's definitely too much going on in the UI thread. Even
after the page paints, I'm seeing multi-second pauses while additional stuff
comes in, where the browser process is unresponsive (example: iGoogle with a
bunch of gadgets). It's not clear to me why any http resource loadi
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote:
>
> I spent a chunk of last week looking at the new tab page performance
> on startup on the Mac. I found that the renderer was waiting on data
> from the browser process for what seemed like far too long. The key
> to this problem is that re
19 matches
Mail list logo
