These graphs look amazing! I'm very much looking forward to doing them for Shumway: I'm sure we can glean some info from them about how to optimize that codebase, itself.
Three quick comments on the UI: - the roll out to the bottom from the graph doesn't work, so the block-tooltips stay around if you move the mouse down from the graph to the list - it'd be great to be able to sort the scripts list by the various columns - I don't know if this easily done, but having invocation counts in addition to total time would be great for the scripts list thank you! till On Fri, Jul 19, 2013 at 7:05 AM, <[email protected]> wrote: > I took the time to get tracelogging up and running again and create V2 out > of it. I think most know tracelogging already, but for those that don't: > > Tracelogging traces when which scripts runs and which engine we use for > it. Out of the log information I create graphs showing when which engine is > run. The graphs are visible on http://alasal.be/ionmonkey/ currently only > for Octane. > > So what is this reviving about. I had to patch spidermonkey properly again > after baseline got added and jeagermonkey was removed. The patch to do this > is in https://bugzilla.mozilla.org/show_bug.cgi?id=895019 and will get > into mozilla-inbound as soon as it is open for some decent time. Everybody > can trace any script by providing the --enable-trace-logging to > ../configure (64bit only atm, I don't have enough registers on 32bit). > Afterwards when a scripts run the information will be logged to > /tmp/tracelogging.log. > > I also created a python script to get some meaningful information out of > it. Nice graphs ;). But actually much more info can get out of it. It's > that file I used to profile octane and find problems in it. The python > script that create nice graphs is on > https://github.com/haytjes/tracelogger (generate.py). > > I want to get this running automatically again. I'm looking into that, but > I'll probably need a dedicated machine/hosting for this. Something like > arewefastyet. So that's coming ;). > > So I now made the graphs for octane, normal and the GGC version. > > Some things I noticed on the graphs: > 1) Nice work Terrence with GGC. The graphs of raytrace and earley-boyer > are much nicer on it > > 2) There is something strange going on with Splay GGC. We could be much > faster on it. It seems like we are stuck in baseline on splay.js:49 for a > lot of time! That function is doing nothing but returning a value, but > somehow that takes 25% of the execution time (excluding gc). I guess > something bogus is happening there. We don't have this issue on Non-GGC > branch > > 3) Deltablue is taking 13% for compiling. That is a lot. Mostly caused by > GC throwing all scripts away. We (terrence, nbp and I) have been talking > and it would be a nice win if we could keep active scripts after GC's. The > consensus was that it shouldn't be that hard and give a nice boost. > > 4) Pdf.js is still our problem child. We are jumping a lot between > baseline and ionmonkey. I still haven't come around to look into it. Some > issues are already reported by nbp. But we still have a long way to go with > this benchmark. > > 5) Mandreel is taking a lot of time compiling. Mind this is IonBuilder > only! (we run parallel compilation). 17% is spend in IonBuilder and we > don't gc. So this is interesting and a nice place for improvement. > > 6) Gbemu runs way to much in baseline. That is 30%. I think we bail a lot > in that benchmark. So we need to find out how to run more in ionmonkey for > this benchmark. > > 7) Code-load runs only in interpreter/baseline. I think that is normal? > Can someone confirm? > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
