Hey Julien, I think your list is spot-on. Luckily, these are all things that both the devtools and the js team are aware of, and efforts are underway or planned for tackling most or all of the things you mentioned.
For the memory analysis tools specifically, check out this planning document: https://wiki.mozilla.org/DevTools/Planning/Performance/Details For other planning tasks around performance, check the parent page: https://wiki.mozilla.org/DevTools/Planning/Performance On Fri, Dec 20, 2013 at 3:24 PM, Julien Wajsberg <[email protected]>wrote: > Hey ! > > I apologize for the cross post, I do this because I think this mail is > useful for both teams. > > 2013 has been a great year for the developer tools. As a regular user of > Firebug and now of the Developer tools, I can see the tremendous > improvements that happened this year. > > Now is a great time to write a wishlist for 2014. This is only a > developer's wishlist, nothing more. > > In 2013 we've mainly seen improvement in the Devtools itself. Now in > 2014 it should be the year where Devtools engineers gets to talk with > other team's engineers (that's why I CC the js engine folks as well). I > know this is already happening, but maybe not enough? > > So here is my wishlist (please cope with any inacuraccies I could make): > * have diagnostics about what happens within the JS engine: > + when and why objects are handled as Hashmap instead of Structs (why > === which JS code is producing this) > + when and why functions are deoptimized > > * have diagnostics about what happens in the memory and other GC-related > stuff > + know when a GC happens (see below for the Profiler) > + have a tool that shows the memory consumption over time (à la > jconsole, cf [1], or visualvm [2]) > + have a tool that shows the various memory generations in a runtime > way (à la visualGC [3]) > + (you can see I did some Java in the past ;) ) > + best of the best: show the JS locations where the most object > creations and deletions happen > > * Have a web developer-friendly profiler > + show the main events happening while a webpage is rendering: css > refresh styles, reflow, repaint > + ideally we should also see _why_ these events are happening, tracing > back to a JS line > + show when a GC happens, show also why this happens if possible and > if it makes sense > > [1] > > http://docs.oracle.com/javase/7/docs/technotes/guides/management/figures/memtab.gif > [2] http://www.cubrid.org/files/attach/images/220547/126/316/visual-vm.png > [3] > > http://www.cubrid.org/files/attach/images/220547/126/316/visual-gc-execution.png > > I can file bugs for all this if they don't already exist, but what I'd > like is to have someone from your team that will make (part of) my > dreams happen. > > The bottom line is: we probably have smaller teams than our competitors, > and that's exactly why we can be better: we can easily talk to each > other, we can be more agile. > > Thanks for reading, have a great party for the end of year! 2014 will be > a great year. > -- > Julien > > > _______________________________________________ > 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
