Comments on: TraceVis: performance visualization for TraceMonkey http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/ Just another Blog.mozilla.com weblog Fri, 20 Nov 2009 22:40:42 -0800 http://wordpress.org/?v=2.8.6 hourly 1 By: 谋智社区 » Blog Archives » 颠覆网络35天 ─ TraceMonkey http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-14147 谋智社区 » Blog Archives » 颠覆网络35天 ─ TraceMonkey Thu, 20 Aug 2009 05:30:53 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-14147 [...] 这里有篇讨论TraceVis的文章可能是目前对TraceVis最全面的解释，包括图表中各种标识的含义以及如何分析性能问题等。这篇文章同样包括一个详细的分析可以帮助更好的理解TraceMonkey的工作远离。 [...] [...] 这里有篇讨论TraceVis的文章可能是目前对TraceVis最全面的解释，包括图表中各种标识的含义以及如何分析性能问题等。这篇文章同样包括一个详细的分析可以帮助更好的理解TraceMonkey的工作远离。 [...]

]]> By: Unleash the power of JavaScript with Mozilla TraceMonkey http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-14038 Unleash the power of JavaScript with Mozilla TraceMonkey Thu, 30 Jul 2009 01:15:03 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-14038 [...] TraceMonkey brings to JavaScript execution in Firefox. David Mandelin has a blog post with a good explanation and visualization of the performance improvement Firefox gets with TraceMonkey. While the excitement around XUL – the Mozilla RIA language [...] [...] TraceMonkey brings to JavaScript execution in Firefox. David Mandelin has a blog post with a good explanation and visualization of the performance improvement Firefox gets with TraceMonkey. While the excitement around XUL – the Mozilla RIA language [...]

]]> By: David Mandelin’s blog » PLDI 2009 http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-11593 David Mandelin’s blog » PLDI 2009 Fri, 12 Jun 2009 21:35:40 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-11593 [...] Nick Nethercote has been fixing up my TraceVis instrumentation so it can be checked into the main Mozilla tree. Soon it should be possible to [...] [...] Nick Nethercote has been fixing up my TraceVis instrumentation so it can be checked into the main Mozilla tree. Soon it should be possible to [...]

]]> By: Was bringt der Firefox 3.5? • Peter Kröner, Webdesigner & Frontendentwickler http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-10850 Was bringt der Firefox 3.5? • Peter Kröner, Webdesigner & Frontendentwickler Tue, 28 Apr 2009 14:24:21 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-10850 [...] ausgeführt werden können. Genaueres zur Funktionsweisen von TraceMonkey findet sich in diesem und in diesem Blogpost – einfach ausgedrückt sucht TraceMonkey nach sich wiederholenden Mustern im Script und [...] [...] ausgeführt werden können. Genaueres zur Funktionsweisen von TraceMonkey findet sich in diesem und in diesem Blogpost – einfach ausgedrückt sucht TraceMonkey nach sich wiederholenden Mustern im Script und [...]

]]> By: Self-improvement « Bill McCloskey’s Blog http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-4154 Self-improvement « Bill McCloskey’s Blog Fri, 20 Mar 2009 19:03:07 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-4154 [...] blog post by my friend Dave perfectly illustrates another topic: the importance of logging, tracing, and [...] [...] blog post by my friend Dave perfectly illustrates another topic: the importance of logging, tracing, and [...]

]]> By: Dan http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-1129 Dan Tue, 03 Mar 2009 18:39:35 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-1129 A very interesting read and the first post by anyone that's actually made me understand how TraceMonkey makes things faster! A very interesting read and the first post by anyone that’s actually made me understand how TraceMonkey makes things faster!

]]> By: Jeroen http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-1124 Jeroen Mon, 02 Mar 2009 07:53:25 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-1124 Hi David, Thanks for your excellent story! I have a question. You say in your trace picture (step 9) that "native code detects that it doesn't fit in an integer". So this means the generated code is also doing extra checks for types and or overflows ? So it's not quite as fast as for example code generated by c compiler? Is this checking because a js int can hold any large value? Thanks again for your nice story, looking forward for the next one ;-) Thx, Jeroen Hi David,

Thanks for your excellent story!
I have a question.
You say in your trace picture (step 9) that “native code detects that it doesn’t fit in an integer”. So this means the generated code is also doing extra checks for types and or overflows ?
So it’s not quite as fast as for example code generated by c compiler? Is this checking because a js int can hold any large value?
Thanks again for your nice story, looking forward for the next one ;-)

Thx,
Jeroen

]]> By: Travis http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-1123 Travis Sun, 01 Mar 2009 03:41:40 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-1123 This reminds me so much of profiling code on the commodore 64. The processor and video chip ran in lockstep. The easy way to profile was to change the screen background color as different parts of the code were running. For programs synchronized with the screen refresh (as most games were, and what else was there to program besides games :^), you would get a nearly stable image of exactly the sort tracevis gives, just rotated 90 degrees. This reminds me so much of profiling code on the commodore 64. The processor and video chip ran in lockstep. The easy way to profile was to change the screen background color as different parts of the code were running. For programs synchronized with the screen refresh (as most games were, and what else was there to program besides games :^), you would get a nearly stable image of exactly the sort tracevis gives, just rotated 90 degrees.

]]> By: TraceVis: Getting some eyes into TraceMonkey | Guilda Blog http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-1121 TraceVis: Getting some eyes into TraceMonkey | Guilda Blog Sat, 28 Feb 2009 12:29:25 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-1121 [...] Mandelin has announcedTraceVis “a visualization of TraceMonkey performance, with the goal of revealing what the JS VM is [...] [...] Mandelin has announcedTraceVis “a visualization of TraceMonkey performance, with the goal of revealing what the JS VM is [...]

]]> By: Boris http://blog.mozilla.com/dmandelin/2009/02/26/tracevis-performance-visualization-for-tracemonkey/comment-page-1/#comment-1119 Boris Sat, 28 Feb 2009 04:06:52 +0000 http://blog.mozilla.com/dmandelin/?p=57#comment-1119 The jsballs benchmark is mostly painting+DOM+css-bound. The time spent in the JS interpreter on it is just a few percent of the total. It can be reduced once we start tracing across DOM method calls (right now those abort trace recording), but that won't help much in terms of benchmark time. This is also why the fact that we run the JS slower on that test with jit on (because we keep starting and aborting recordings) doesn't affect the test results much: it's just not spending that much time in the JS engine to start with. The jsballs benchmark is mostly painting+DOM+css-bound. The time spent in the JS interpreter on it is just a few percent of the total. It can be reduced once we start tracing across DOM method calls (right now those abort trace recording), but that won’t help much in terms of benchmark time.

This is also why the fact that we run the JS slower on that test with jit on (because we keep starting and aborting recordings) doesn’t affect the test results much: it’s just not spending that much time in the JS engine to start with.

]]>