1

I have DPs a and b to which c is bound via i converter (note that a and b might be bound to another DP via a converter). I modify a and b or some of the DPs that they are bound to and then use c in a calculation. I do this in a for loop, and it is taking a really long time, the conditions is i=0; i<100000; i++). So I am wondering how efficient is data binding? And should it be used in scenarios like this? Here is some sample code:

 for ( int i = 0; i < 100000; i++){ //... code to pick m based on some random numbers hazards[m].Reactant1.Count -= 1; hazards[m].Reactant2.Count -= 1; hazards[m].Product.Count += 2; display.Text = hazards[m].Value.ToString(); } 

hazards.Value is bound to the count of the reactants via a converter, the count of the reactants is bound to a textbox text property. m is picked based on the hazard value and some random numbers.

12
  • 2
    Sounds like you should separate the view from the model. Look into MVVM. Commented Jan 11, 2012 at 22:13
  • 1
    @AvadaKedavra I know what MVVM is, but I am not sure how to relate your answer. Commented Jan 11, 2012 at 22:17
  • No it shouldn't. Do it as close to the source as possible, you are only one step away from doing it through a UI grid with this. Commented Jan 11, 2012 at 22:22
  • @TonyHopkinson what is a UI grid? Do you know of any MS sources on the performance of DPs? Commented Jan 11, 2012 at 22:26
  • @JohnnyGraber I added some code. Commented Jan 11, 2012 at 22:31

3 Answers 3

2

I do this in a for loop, and it is taking a really long time, the conditions is i=0; i<100000; i++). So I am wondering how efficient is data binding? And should it be used in scenarios like this?

That is the problem - false test. WHO CARES? If you think you can show 100000 updates on the screen with the user following you are already mistaken. Plus there is the problem of how / when the screen updates on a tight loop scenario - you may well be bound to 60 updates per second.

You do NOT test data binding to start with, you test ALSO 100.000 tostring calls.

Sign up to request clarification or add additional context in comments.

Comments

1

The right way here will be to separate view from the model. For this purpose use MVVM (there are a lot of nice implementations of INotifyPropertyChanged in web). When ViewModel will be prepared (I meen base ViewModel)- should implement something like:

[ViewModel].cs :

private double _c; public double C { get { return _c; } set { if (_c != value) { _c = value; RaisePropertyChanged("C"); } } 

[Page].xaml

... <UserControl.Resources> <vm:ViewModel /> ... </UserControl.Resources> ... <TextBox x:Name="A" Text="{Binding C, Converter={StaticResource someConverter} Mode=TwoWay}" /> ... <TextBlock x:Name="B" Content="{Binding C, Mode=TwoWay}" /> ... 

After changing C from ViewModel or View it will automatically (with INotifyPropertyChanged help) update it in all bound places. This means that you should not run any loops or whatever you do before.

NOTE: From scratch I advise to use MvvmLight.

1 Comment

Interesting Idea, I will look into the links. Thank you.
0

Long running task should never be run in the UI thread. If you run your long running calculation here your UI will be slow - independently of the speed of data binding. Since you block the updates of the UI.

If you change the value in a background thread then you have to use a dispatcher who makes a thread switch for you. This again comes with an overhead.

In both ways you have many factors who will slow down your application. And it doesn't really say anything reliable on the efficiency of data binding.

I suggest you write your code in a background thread and check if it is fast enough. If not use a profiler to check where your bottleneck is.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.