3

just a simple question on data updating. Suppose I have a TextBox called txtBox1 and I want to update the value of a string variable called foo.

Which gives the best performance and best to do?

// The lengthier code but will check if the value is the same before updating.
if (foo != txtBox1.Text)
     foo = txtBox1.Text;

or

// The shorter code but will update it regardless if it's the same value
foo = txtBox1.Text;
CudoX
  • 985
  • 2
  • 19
  • 31

2 Answers2

3

It really depends on what you do with foo variable.

If updating foo involves updating other parts of your application (via data binding for example) then yes, you should only update it when necessary.

GETah
  • 20,922
  • 7
  • 61
  • 103
  • So if I'm just going to update foo without connection to other parts (for example, foo is just an undo preference), *foo = txtBox1.Text;* is recommendable or it's still the longer case? – CudoX Dec 09 '13 at 01:11
  • Update foo only when the value changes and you should be fine. Updating it all the time will have minor performance hit in this case – GETah Dec 09 '13 at 15:40
1

Original Answer

Warning: I messed up... this answer applies for the opposite case, that is:

txtBox1.Text = foo

It may depend on what TextBox you are using...

I haven't reviewed all the clases with that name in the .NET framework from Microsoft. But I can tell for System.Windows.Forms.TextBox that the check is done internally, so doing it yourself is a waste. This is probably the case for the others.


New Answer

Note: This is an edit based on the comments. It it taken from granted that the objective is keep track of the modifications of the texbox and that we are working in windows forms or similar dektop forms solution (that may be WinForms, WPF, GTK#, etc..).


IF you need every value...

TextChanged is the way to go if you want a a log or undo feature where you want to offer each value the textbox was in.

Although take note that the event runs in the same thread as that the text was assigned, and that thread ought to be the thread that created the textbox. Meaning that if you cause any kind of lock or do an expensive operation, it will heavily^1 impact the performance of the form, causing it to react slowly because the thread that must update the form is busy in the TextChanged handler.

^1: heavily compared to the alternative presented below.

If you need to do an expensive operation, what you should do is add the values to a ConcurrentQueue<T> (or similar). And then you can have an async^2 operation run in the background that takes the values from it and process them. Make sure to add to the queue the necessary parameters^3, that way the expensive operation can happen in the background.

^2: It doesn't need to be using the async keyword, it can be a ThreadPool, a Timer, a dedicated Thread or something like that.

^3: for example the text, and the time in the case of a log. If have to monitor multiple controls you could also consider using a POCO (Plain Old CLR Object) class or struct to store all the status that need to be kept.


IF you can miss some values...

Using the event

Use the event to update a version number instead of reading the value.

That is, you are going to keep two integer variables:

  1. The current version number that you will increment when there were a change. Use Thead.VolatireWrite for this (there is no need for Interlocked)

  2. The last checked version number that you will update when you read the values from the form (this done from an async operation), and that you will use to verify if there has been any updates recently. Use Interlocked.Exchange to update the value and proceed if the old value is different from the readed one.

Note: Test the case of aritmetic overflow and make sure it wraps MaxValue to MinValue. No, it will not happen often, but that's no excuse.

Again, under the idea that it is ok to miss some values... If you are using a dedicated Thread for this, you may want to use a WaitHandle (ManualResetEvent or AutoResetEvent [and preferably it's slim counterparts]) to have the thread sleep when there hasn't been modifications instead of having it nopping (spin waiting). You will then set the WaitHandle in the event.

Theraot
  • 31,890
  • 5
  • 57
  • 86
  • Tried it with the *TextChanged* event and it skips it when the texts are the same. However, it still causes *Validation* (which is important in my case). Assuming that the texts are 100% the same, is this still a better option? The longer case just updates it when necessary so there's no *Validating* event when they're the same. – CudoX Dec 09 '13 at 01:06