﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Lee Campbell commented on Tracking NH Prof performance problem on aggressively active application</title><description>From a purely WPF point of view, why is the code like this:
  
  
dispatcher.Invoke((Action)delegate
  
{
  
	//From here on in I am blocking the UI thread. :-(
  
	using(dispatcher.DisableProcessing())
  
	{
  
		var sp = Stopwatch.StartNew();
  
		foreach (var action in actions)
  
		{
  
			action();
  
		}
  
		Debug.WriteLine(remainingCount + "\t" + sp.ElapsedMilliseconds);
  
	}
  
}
  
  
  
when I would have thought you would get the result you are chasing from this:
  
  
foreach (var action in actions)
  
{
  
//non blocking call. This queues the action to be performed by the dispatcher. Optionally provide a Priority for the action to provide beter responsiveness.
  
	dispatcher.BeginInvoke(action);	
  
}
  
  
On a design point of view, if your presentation model is too verbose can you only work with "Summary objects" which represent a summary of the data which is more digestible at a higher level. Drilling in offers more information. Using the Group/Sort/Filter functionality of things like CollectionViewSource the power moves back to the XAML on how to present the data.
  
  
See 
[leecampbell.blogspot.com/.../...ispatchers-to.html](http://leecampbell.blogspot.com/2009/01/responsive-uis-in-wpf-dispatchers-to.html) for more info on Responsive UIs in WPF.
  
  
HTH
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment20</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment20</guid><pubDate>Mon, 16 Feb 2009 15:00:06 GMT</pubDate></item><item><title>Peter Morris commented on Tracking NH Prof performance problem on aggressively active application</title><description>I think you are misunderstanding what I am saying.  I am not suggesting pushing the data.  What I am suggesting is
  
  
01: Thread which adds the data notifies there is data available by ensuring a manual reset event remains signalled.
  
  
02: The thread which you are currently polling with (which is wasteful when there is no data to process) is replaced with a thread pool wait, so it doesn't cost a thread.
  
  
03: When the event is signalled and a thread is assigned you update the GUI with a small window of the latest data.
  
  
04: Once finished binding the GUI reschedules another thread pool wait.
  
  
By polling you are pulling from the data, but still pushing in the GUI.  By using this approach you are eliminating the wasteful polling and also ensuring that the GUI pulls and nothing is ever pushed into it and it updates as often as it can.
  
  
If you poll then the duration might be fine on your PC but too frequent on a slower PC with a rubbish graphics card, or not frequent enough on a really powerful PC.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment19</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment19</guid><pubDate>Mon, 16 Feb 2009 09:45:44 GMT</pubDate></item><item><title>Ayende Rahien commented on Tracking NH Prof performance problem on aggressively active application</title><description>Peter,
  
That is actually what is going on right now.
  
That is a problem, because push model doesn't work for UI in this scenario.
  
I'll talk about this a bit more in an additional post
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment18</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment18</guid><pubDate>Mon, 16 Feb 2009 01:09:07 GMT</pubDate></item><item><title>Peter Morris commented on Tracking NH Prof performance problem on aggressively active application</title><description>No need to poll is there?  What about this
  
  
01: Have a manual reset event in your queue.  Set it when you add your first item, reset it when the last item is removed.
  
  
02: Add an item to the ThreadPool that is waiting for the manual reset event.
  
  
03: When the event is signalled a thread is scheduled to update the GUI.  At the end of updating the GUI you queue another item to the ThreadPool.
  
  
This way you''' get an instant update to the GUI when new data arrives, but will only update the GUI as often as it can handle it.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment17</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment17</guid><pubDate>Sun, 15 Feb 2009 09:52:41 GMT</pubDate></item><item><title>gnash commented on Tracking NH Prof performance problem on aggressively active application</title><description>We just released 0.4.1.6 of Retlang that makes asynchronous communication with Windows Forms much easier.  The new class is called FormFiber.  It will give you all of the batching, scheduling, etc. of Retlang but on the Form thread.  It uses ISynchronizeInvoke, instead of using the Dispatcher, but I believe the interface still exists on WPF Forms.
  
  
[http://code.google.com/p/retlang/](http://code.google.com/p/retlang/)</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment16</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment16</guid><pubDate>Sat, 14 Feb 2009 01:20:33 GMT</pubDate></item><item><title>mendicant commented on Tracking NH Prof performance problem on aggressively active application</title><description>You already answered your last question: 
[ayende.com/.../...to-commentors-it-is-my-blog.aspx](http://ayende.com/Blog/archive/2009/02/06/newsflash-to-commentors-it-is-my-blog.aspx)  
  
:D
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment15</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment15</guid><pubDate>Fri, 13 Feb 2009 22:31:11 GMT</pubDate></item><item><title>dave-ilsw commented on Tracking NH Prof performance problem on aggressively active application</title><description>I think it's great that you're willing to do detailed design for NH Prof problems on your blog.
  
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment14</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment14</guid><pubDate>Fri, 13 Feb 2009 19:09:45 GMT</pubDate></item><item><title>Peter Seale commented on Tracking NH Prof performance problem on aggressively active application</title><description>Re: NHProf blogging, 
  
  
It's better that you post what you care about, rather than trying to manufacture posts when that design issue is bugging you. For an analogue, see the recent posts on CodingHorror vs the recent posts on blog.stackoverflow.com vs fakeplasticrock.com - all three by Jeff Atwood (and no I don't read all three) - the point is, if you compare the three blogs, it's clear that CodingHorror isn't the one he's passionate about. Which is really unfortunate for his 124k subscribers :)
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment13</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment13</guid><pubDate>Fri, 13 Feb 2009 16:26:58 GMT</pubDate></item><item><title>Peter Morris commented on Tracking NH Prof performance problem on aggressively active application</title><description>You can still bind, but to a snapshot of the view data.  Get a notification whenever it updates, lock, snapshot the bit you want to show, unlock, bind to the snapshot.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment12</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment12</guid><pubDate>Fri, 13 Feb 2009 14:10:43 GMT</pubDate></item><item><title>Shane Courtrille commented on Tracking NH Prof performance problem on aggressively active application</title><description>We're here for the most part for your views on software development.  It doesn't get any more real then the thought process behind how you are developing your commercial application.  Keep going!
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment11</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment11</guid><pubDate>Fri, 13 Feb 2009 14:03:32 GMT</pubDate></item><item><title>Chris Cyvas commented on Tracking NH Prof performance problem on aggressively active application</title><description>I'm diggin' it. I have skin in the game too. But, this is pretty interesting stuff regardless of that.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment10</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment10</guid><pubDate>Fri, 13 Feb 2009 13:19:43 GMT</pubDate></item><item><title>Ayende Rahien commented on Tracking NH Prof performance problem on aggressively active application</title><description>Avish,
  
The problem is that now I have to track all of my UI changes and actively force then, rather than let the binding do that.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment9</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment9</guid><pubDate>Fri, 13 Feb 2009 12:03:16 GMT</pubDate></item><item><title>Avish commented on Tracking NH Prof performance problem on aggressively active application</title><description>I agree with Peter, perhaps it'd be best to not rebind on every model update, but rather to raise some sort of "dirty" event. The view will then repoll the dirty parts of the model when it sees fit, and only those that it wishes to show. 
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment8</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment8</guid><pubDate>Fri, 13 Feb 2009 09:53:46 GMT</pubDate></item><item><title>Peter Morris commented on Tracking NH Prof performance problem on aggressively active application</title><description>In addition :-)  The GUI then also only needs to copy out of the view data what it is currently showing, like a virtual data source.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment7</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment7</guid><pubDate>Fri, 13 Feb 2009 05:17:32 GMT</pubDate></item><item><title>Peter Morris commented on Tracking NH Prof performance problem on aggressively active application</title><description>What does Action do?  Update the GUI?  If so I would change it to update some view data instead.  The GUI should poll the view data whenever it is ready.  This way the ViewData can get updated as often + as quickly as it needs to, and the GUI can lock, copy out the data it needs, then bind to the copy as frequently as it can manage.
  
  
It would be easier with a simple test case though :-)
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment6</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment6</guid><pubDate>Fri, 13 Feb 2009 05:13:37 GMT</pubDate></item><item><title>Ayende Rahien commented on Tracking NH Prof performance problem on aggressively active application</title><description>Andrew,
  
Okay, it isn't what you think it is.
  
Now tell me what the problem is?
  
If you are going to tell me that this snuffle the entire list, I know.
  
I don't really care for this particular implementation.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment5</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment5</guid><pubDate>Fri, 13 Feb 2009 04:01:18 GMT</pubDate></item><item><title>Kyle Szklenski commented on Tracking NH Prof performance problem on aggressively active application</title><description>Andrew, I guess it depends on what queuedActions' type is. If it is a non-contiguous collection, removing the first one like that won't be updating any indices, so there's no performance issue. It's also possible that it's a custom queue that has its own custom RemoveAt, but if that were the case, I would think Oren would write it a little differently. There's probably not really a performance issue anyway - that type of thing can really fly when there's only 100 items in the list (and he's guaranteed that), and it's clearly the issues that Oren brought up initially that would be the performance concern. I would still move it to removing actions from the backend backwards, but that's just because I tend to always iterate through collections backwards. It saves a lot of headaches.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment4</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment4</guid><pubDate>Fri, 13 Feb 2009 03:54:03 GMT</pubDate></item><item><title>Kyle Szklenski commented on Tracking NH Prof performance problem on aggressively active application</title><description>Do I care? Yes. Do I want you to continue? Yes. This stuff is great - you can't get a more detailed analysis of problems on the net, especially not with a real-time, real-life application that is being developed. It shows some incredible balls on your part. :) I salute you, sir!
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment3</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment3</guid><pubDate>Fri, 13 Feb 2009 03:47:07 GMT</pubDate></item><item><title>Andrew Peters commented on Tracking NH Prof performance problem on aggressively active application</title><description>Please tell me this:
  
  
queuedActions.RemoveAt(0);
  
  
isn't what I think it is.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment2</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment2</guid><pubDate>Fri, 13 Feb 2009 03:40:47 GMT</pubDate></item><item><title>Mr_Design commented on Tracking NH Prof performance problem on aggressively active application</title><description>Since I purchased a license and have skin in the game, I'm happy with you doing design on the blog.
</description><link>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment1</link><guid>http://ayende.com/3869/tracking-nh-prof-performance-problem-on-aggressively-active-application#comment1</guid><pubDate>Fri, 13 Feb 2009 02:57:55 GMT</pubDate></item></channel></rss>