Library tutorials & articles
Performance Issues
The magic $
Many of you will have noticed that there is both a Mid and a Mid$ function, as well as Left$, Right$, and a number of other functions. However, it is not obvious what the difference actually is. When you use the Mid function, it returns a string as a Variant data type. As you would normally save the result to a string, not a Variant, Visual Basic then has to convert the Variant into a string. When you use the Mid$ function, it returns a string in a String variable. This saves Visual Basic the trouble of converting the Variant to a String, and thus increases performance. When you perform long loops of code, using Mid, and the other string functions, this can make quite a difference. I have yet to find an instance when you would actually want the Mid statement to return a Variant, and not a String, so I am not sure why Microsoft have done this. To see a list of all the procedures that have a $ (string) version as well, open the object browser (F2), enter $ into the find box, and press Find. This will give you a list of about 25 procedures where this is the case.
James first started this website when learning Visual Basic back in 1999 whilst studying his GCSEs. The site grew steadily over the years while being run as a hobby - to a regular monthly audience ...
Related articles
Related discussion
-
VB6 Runtime error 381 subsript out of range Error
by Uncle (2 replies)
-
passing and reading parameters from using Shell
by jigartoliya (0 replies)
-
Convert C++ code to VB6
by mawcot (4 replies)
-
listbox scrollbar
by Dennijr (10 replies)
-
Can you describe Above simple VB6 code?
by pramodmca09 (0 replies)
Related podcasts
-
Christian Beauclair
14 mai 2008 (�mission #0074) ::.Christian Beauclair: Stratégies de migration VB6 vers .NET Nous discutons avec Christian Beauclair des stratégies de migration VB6 vers .NET. Entre autres, nous discutons comment utiliser le "VB 6 Code Advisor" et le "Interop Forms Toolkit" pour ajouter la puiss...
And once again a greate article by james!
This posting is specifically a response to James Cowleys suggestion that using ByVal is quicker than using ByRef. This is only true when calling an out-of-process server (i.e. and ActiveX EXE). VB is designed to pass all parameters ByRef, which means that everything is passed as a 32-bit pointer. When passing ByVal VB copies the contents of the parameter into temporary space and then passes a 32-bit pointer to the temporary space. This means that, counter-intuitively, it is slower passing a long ByVal than it is ByRef.
When calling an out-of-process server OLE must marshal a copy of your parameter into the address space of the routine you are calling and then, if it is ByRef, copy it back afterwards. This is probably the only occasion that passing ByRef is slower.
Generally ByVal should be reserved for occasions when the routine is going to change the contents of the variable and the calling routine will be affected by the change. At the very least use ByRef for all strings and variants.
This thread is for discussions of Performance Issues.