Recent searches
Search options
It's fun to look back at how things evolve. In 2012, my team was working on creating a UI responsiveness tool for IE and Visual Studio (for Windows Store apps written using JavaScript). This was at a time when many of the default Windows applications were written using JS and we didn't have good tools for the Window's team to analyze performance problems. It took us a few sprints to get the data collection, analysis, and UI to be useful.
The first iteration was focused on building out reusable controls and on reading and analyzing ETL files via script. The UI that we actually integrated in VS during that time was extremely minimal and allowed us to see the data processing and event layout: 2/
In the next sprint we enabled dynamic collection of data and added the initial CPU graph. 3/
The following sprint saw much better integration between the CPU graph and timeline, enabling range selection, zooming in/out, life cycle events, user generated events, etc. At this point, the tool actually became useful for the app writers :) 4/
Eventually, the tool matured into the IE10/11 and early Edge (before Chromium integration) tool used for performance analysis, and looks like this: 5/
Although Edge is using the Chrome developer tools now, I’d like to think that the progress we made on the IE developer tools helped spur some innovation on the Chrome side as well. Chrome added a CPU graph, frames, etc. as well (the tools are now substantially more advanced :).
These same controls, layout, etc. were also used for the .NET UI responsiveness tooling. 6/ fin