Woodstock is now much faster

November 19, 2007

I performed some stress testing on Woodstock today, and found a couple of weak points in the code which prevented it from working well with absurdly large visual trees.  By “absurdly large” I am referring to a visual tree with at least 10,000 elements in it.  Huge, huge, huge visual trees.  It should not be too often that a WPF user interface has a visual tree of that immense size, but I wanted to be sure that Woodstock can handle it well (up to a certain point).

The two performance enhancements that I addressed are:

1) Nodes in the TreeView are now loaded on-demand.  When you expand a node in the TreeView it then loads the children of that node, if they are not already loaded.  This drastically reduces the load time for the Woodstock window when your visual tree has thousands of items in it.

2) The children of a WpfElement are now temporarily removed from its Children property, just prior to that element being sent over to the debuggee process to be populated with property information and a snapshot image.  When the freshly populated WpfElement is returned back to the visualizer its child elements are added back to its Children property.  This can cut down the amount of time it takes to get the property information and snapshot for a WpfElement, especially if that element has a very large number of descendant elements.

The new bits are available here:  http://www.codeproject.com/useritems/WoodstockForWPF.asp

Enormous improvements to Woodstock

November 17, 2007

I solved the BIG problem in Woodstock today.

It dawned on me that I can lazily load the element property information and snapshot images, by having two-way conversations between the debugger and debuggee processes, just by using the standard Visualizer API! This means that the whole timeout problem is gone, because a huge amount of data is no longer being serialized all at once. And, this enabled me to add in support for viewing snapshot images of every element in the tree, not just the one you initially selected!!

I added a thorough explanation of how all this works to the article in the “Lazily Loading Element Information” subsection, under the “How It Works” section. I’m so glad that I finally resolved this crippling issue. Now Woodstock is a truly reliable, robust, fast, and dependable WPF debugging tool.

The only remaining issue that I know of is if you let it run for a long time. Eventually a RemotingException is thrown while some GDI+ code is executing, and the visualizer crashes. I don’t think there’s a way for me to work around that bug…

Go get it! http://www.codeproject.com/useritems/WoodstockForWPF.asp

Significant improvements to Woodstock

November 15, 2007

I woke up extra early this morning to implement a bunch of the really awesome feature requests people have sent me for Woodstock.   The article and file downloads have been updated, so feel free to drop by and get the latest bits: http://www.codeproject.com/useritems/WoodstockForWPF.asp

Here is a summary of what’s new:

A case insensitive property filtering TextBox, allowing you to quickly find a property in the grid.

A CheckBox which allows you to hide the attached properties in the grid.

The “Property Name” column now contains links which copy a Google search to your clipboard.  That URL can be put into a Web browser’s address box to easily search for the property you clicked on.  I wanted to just open a Web browser to that URL, but VS crashed when I did that.  

Also I made some optimizations to the serialization code, hoping to avoid the dreaded “Function evalution timed out” error message.

Now here’s a bug which I don’t know how to work around!  Check out this freakishness, which occurred when I left Woodstock running for about 15 minutes:

Woodstock Weirdness


I suppose we should all be writing our GDI+ code like this;

try { this.FontsAreEqual = someFont.Equals(fooFont); }

catch(RemotingException e) { Debug.WriteLine(“WTF?!?!?!?!”); }

More updates to Woodstock

November 14, 2007

The interest people are showing in Woodstock is blowing my mind.  I have been receiving all types of feedback about it ever since posting the article.  Andrew Smith, from Infragistics, pointed out a much smarter way of getting all the properties of an element (including attached properties!).  I updated the code and article using his technique instead.

I also received some feedback saying that Woodstock was “timing out” in some situations.  It turns out that Visual Studio’s “Debugger Visualizer” feature only allows a visualizer to have a brief amount of time to serialize its data, which is then sent to the visualization display.  If your visual tree is really big, or your machine is bogged down from some other process, or your machine just plain old sucks, then Woodstock won’t have a chance to do its work before timing out.  I tested it out on Times Reader (which has a gigantic visual tree) and, sure enough, was able to reproduce the problem.

To address the issue I did some optimizations to help speed up the serialization process.  The biggest gain was when I made WpfElementProperty a struct instead of a class.  Since hundreds of thousands of those instances can be created for one visual tree, it really made a difference.  If you see any other ways to optimize the code which saves information about the visual tree in Woodstock, please let me know.

I updated the article and downloads, so I suggest you go and get the latest drop.  Enjoy!