And then gather statistics to see mean & variance. Find high-latency operations and target as areas for improvement for UI responsiveness.

bulldozer to M12

I suck.

Why?

hey warren, why don't you do this as part of your "add instrumentation to the browser" crusade. thanks.

To answer warren's "why?" -- because we keep running into cases where some control flow from the event loop hogs the CPU for too long, and we'd like to know when that happens too often, how long we spend away from the loop on average, and min and max to boot -- doing this by event (event type histogram) would help us assign blame and credit, and move our code toward responsiveness. /be

No, I meant why does Chris suck?

Duh. Waterson rules, but he was obviously feeling guilty about not fixing this bug in M12. /be

Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.

I tried this, but came up with a very large standard deviation due to the fact that my timing didn't subtract out thread switching time. There's some code in stopwatch.c for unix that deals with cpu time instead of real time -- I'm going to integrate that into my new stopwatch class.

Isn't real time what we're interested in though?

Moving non-essential, non-beta2 and performance-related bugs to M17.

post-beta2

This bug has not been touched for more than nine months. In most cases, that means it has "slipped through the net". Please could the owner take a moment to add a comment to the bug with current status, and/or close it. Thank you :-) Gerv

Milestone 0.8 has been released. We should either resolve this bug or update its milestone.

maybe mcafee could look at this????

mcafee, are you looking at this? blizzard expressed interest doing some profiling on linux.

no this isn't on my radar, blizzard is welcome to take a look.

OK, I'm assigning this to myself. It's going to be a couple of weeks, though so if someone else has the itch first they are more than welcome to steal this bug back.

I suspect most of the latency will be limited to the dispatching of the user-events posted when there is a pending PL_Event. This is because parsing/content model creation and reflowing are driven by PL_events. Mouse events which fire event-handlers may result in changes which need time-consuming reflows but in this case the mouse event will result in scheduling of a reflow PL_event which will be processed when the user-event is dispatched in the message loop.

What is the current status on that?

Is this somehow also related to bug 169247 ? What is still reported is when users run performance tests (dhtml) and they move around the mouse the tests improve. this seems to be a win32 event issue - and processing of timeout is also 'unstable'.

attached latprof.c It's a bit of a hack (not very thread safe), but seems to be useful. It instruments poll/select, trigers a timer and reports stack traces when there a signal is received. compile instructions on top of the file, use it with LD_PRELOAD Some day, I'll hack this into memprof.

I seem to recall shaver putting in some time working on something like this on Mac recently-ish -- not sure what stage that's at right now, and I doubt it used your mechanism, but I'm sure he'd be interested in it!

http://shaver.off.net/diary/2007/08/25/tbeachball/ has my patch, should work cross-platform. Doesn't have stack traces, which is an interesting approach when combined with a watchdog!

It would be really great if we could revive this - it's important for mobile profiling (which pages do we lag badly on?) and desktop as well as people have many many tabs open. We've been taking a brute force approach to a lot of performance, which is really nice, but interaction performance is an area where we don't have any measurements.

I wanted to do this with dtrace events, which would (at least in theory) allow you to generate profiles of the loops that take too long. I'm guessing that's not what you want for mobile?

I don't think we have dtrace on any of our mobile platforms. Does my simple patch work on the mobile platforms? Seems like it would give you useful data, though you might have to set a conditional breakpoint or something to investigate further.

(In reply to comment #22) > Created an attachment (id=294849) [details] > latprof.c - linux latency profiler > > attached latprof.c > > It's a bit of a hack (not very thread safe), but seems to be useful. > It instruments poll/select, trigers a timer and reports stack traces when there > a signal is received. > > compile instructions on top of the file, use it with LD_PRELOAD > > Some day, I'll hack this into memprof. I tried this out and got some good results. However, it often hung because of calls malloc() in the signal handler.

I have patches in bug 606574.