Persistent Realities » Home

Site
News
Files

Visual Basic
Strings
Math
General
Properties
Memory
Methods

Inline ASM-VB
Strings
Math
General
Memory

Caching property variables

I used less iterations than normal, now: 500. Because tests took (very) long if I increased this to to a tenfold or even more. But there is no doubt. Using a temporary variable to assign data to a property is much faster than assigning data directly. Ofcourse it doesn't apply to all controls. But with this textbox it certainly did.

Used (partial) code:

Code: For I = 1 To lngIterations '//Run test '//Test One Form1.Text1.Text = Form1.Text1.Text & "This is an test" & vbCrLf Next I

Code:
        For I = 1 To lngIterations '//Run test
            strTemp = strTemp & "This is an test" & vbCrLf
        Next I
        Form1.Text1.Text = strTemp

Without % faster than With	Without (sec)	With (sec)
7261,7%	0,725878	0,009860
6829,8%	0,658609	0,009504
6637,8%	0,650746	0,009658
6600,8%	0,659363	0,009840
6740,8%	0,659377	0,009639

User contributed notes:

Author: EACam (empyrianpale at juno dot com)	Date: 22:04 21/04/2004
Uhhggg...those commas for british instead of points (periods) for enlish is confusing...oh well.
Author: ViX44 ()	Date: 17:05 31/05/2004
It's the "This is an test" thing that throws me...colour coding the IS, and using AN in front of a consonant.
Author: Almar Joling ()	Date: 18:05 31/05/2004
Some people are not native English speaking. the IS comes from "Is Nothing", as you probably have used before.
Author: BYTE-Smasher ()	Date: 21:11 16/11/2004
I'm pretty sure the results of this test would be different depending on the control... the textbox.text is a very intensive property... each time it's called, the textbox has to slice the text into lines (for multiline) and it's also clipping the text that's not displayed... if you test this out with a homemade class that just stores the property value, you will get much different results...
Author: Comintern ()	Date: 22:03 15/03/2005
Example one calls both the property let and property get for Form1.Text1 each time through the loop. This is like 2 function calls compared to a string assignment.
Author: Almar ()	Date: 22:03 15/03/2005
So, exactly why you need to cache the properties.
Author: Steven Noonan (steven at uplinklabs dot net)	Date: 04:05 11/05/2005
I can actually explain why this is true in this case. Each time you add something to a text box, it redraws it. If the text box were not visible, I'd bet you'd get faster results from 'text1.text = text1.text &' than you have displayed here.
Author: Tom (hurendo_kun at hotmail dot com)	Date: 15:05 31/05/2005
That could be one reason, but primarily it's because the Text property is a string, and non-fixed strings are very heavy on memory allocations and copies. (Look at the COM descriptor for a string sometime; you'll see it's very much like a class.) Use temps with any data that's processor- or memory-intensive. Ignore them for singular units (Longs, singles, etc.). Of course, I generally consider copying strings a bad idea to begin with, but sometimes it's necessary.
Author: Tom (hurendo_kun at hotmail dot com)	Date: 16:06 08/06/2005
"Singular units. . ." ugh that's terrible. I meant to say "intrinsic types." :P
Author: Tom (hurendo_kun at hotmail dot com)	Date: 05:09 23/09/2005
On second thought, that doesn't really explain the huge difference, because strTemp and Text1.Text are both ordinary strings. It could be the access operators (.), but I prefer to think Steven is right. Even without a DoEvents clause, something is likely happening under the hood that's pushing this loop to a crawl.
Author: Tom (hurendo_kun at hotmail dot com)	Date: 19:10 21/10/2005
More research. Steven is definitely right. Set AutoRedraw to False before running this function, or better yet, make it invisible. The access operator (.) is also slowing things down. Temp variables are just a good idea in general.