dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 5 of 5

Thread: ByVal vs ByRef

  1. #1
    Eric D. Burdo Guest

    ByVal vs ByRef

    I understand the difference between ByVal and ByRef. My questions stems
    from something I was told by several VB programmers:

    ByRef is faster than ByVal.

    However, I have been reading the book VB6 Error Coding and Layering by Tyson
    Gill. He states that although ByRef is faster, it is not measurable in most
    cases, and recommends using ByVal for safety purposes (less errors and such
    because you cannot modify the value).

    Is he correct? How measurable is the speed difference between ByVal and
    ByRef? I am not concerned with external stuff (dll's and such) but just
    within the project.

    --

    Eric D. Burdo, Red-Leif International
    VB Programmer and Consultant
    <http://www.redleif.com/vb>

    *** Please reply to the newsgroup so all can benefit. ***





  2. #2
    ralph Guest

    Re: ByVal vs ByRef


    "Eric D. Burdo" <vbtips@redleif.com> wrote:
    >I understand the difference between ByVal and ByRef. My questions stems
    >from something I was told by several VB programmers:
    >
    >ByRef is faster than ByVal.
    >
    >However, I have been reading the book VB6 Error Coding and Layering by Tyson
    >Gill. He states that although ByRef is faster, it is not measurable in

    most
    >cases, and recommends using ByVal for safety purposes (less errors and such
    >because you cannot modify the value).
    >
    >Is he correct? How measurable is the speed difference between ByVal and
    >ByRef? I am not concerned with external stuff (dll's and such) but just
    >within the project.
    >
    >--
    >
    >Eric D. Burdo, Red-Leif International
    >VB Programmer and Consultant
    ><http://www.redleif.com/vb>
    >
    >*** Please reply to the newsgroup so all can benefit. ***
    >
    >
    >
    >


    You shouldn't base all your implementations on "performance" alone. To paraphase
    Bruce McKinney - "It doesn't matter how fast it is if it doesn't work"!

    In most situations ByRef is faster than using ByVal. However,
    as you mentioned there are very good reasons to use ByVal.

    For example, if I had a member function that took a couple of strings, hammered
    on them, then returned a new string - I have to have a method to insure that
    invariance is preserved. So I would have two choices: 1) Bring in the strings,
    copy them to locals and hammer on the locals, or 2) Let the O/S create copies
    for me.

    In this case, it is probably faster to let the O/S create the copies. But
    the point is it doesn't matter!

    If I have to protect the incoming. I have to protect the incoming, Period.
    Declaring the routine ByVal does this and makes it very clear to anyone else
    that these parameters are protected.




  3. #3
    Bob Butler Guest

    Re: ByVal vs ByRef

    "Eric D. Burdo" <vbtips@redleif.com> wrote in message
    news:39edb8f2$1@news.devx.com...
    > I understand the difference between ByVal and ByRef. My questions stems
    > from something I was told by several VB programmers:
    >
    > ByRef is faster than ByVal.


    That is not always true.

    > However, I have been reading the book VB6 Error Coding and Layering by

    Tyson
    > Gill. He states that although ByRef is faster, it is not measurable in

    most
    > cases, and recommends using ByVal for safety purposes (less errors and

    such
    > because you cannot modify the value).


    In general, I agree with that.

    > Is he correct? How measurable is the speed difference between ByVal and
    > ByRef? I am not concerned with external stuff (dll's and such) but just
    > within the project.


    When you pass ByVal within a project the value is copied and the copy is
    passed ByRef (essentially). If it's a Long value then the time difference
    is negligible. If it's a 32KB string then it takes longer since it has to
    allocate the memory and do the copy. Passing ByRef means the called routine
    operates directly on the original copy making ByRef faster than ByVal.

    When you pass out-of-process the value has to be copied whether it is ByRef
    or ByVal (it has to get there somehow) but if it is ByRef and is changed it
    has to be copied back... that makes ByRef slower than ByVal.




  4. #4
    Matthew Curland Guest

    Re: ByVal vs ByRef

    > Is he correct? How measurable is the speed difference between ByVal and
    > ByRef? I am not concerned with external stuff (dll's and such) but just
    > within the project.


    For numeric types, you'll have to use something better than Timer to measure
    it, but it is definitely measurable. You might also want to consider the
    code generation when you think about speed. For example, passing a constant
    to a ByRef causes the generated calling to spit a lot more code. Simple
    things like CopyMemory x, 0&, 4 cause a lot of code spit to pass the 0& to a
    ByRef As Any parameter.

    -Numeric types are generally faster ByVal. You just push the Value on the
    stack and walk away. The calling and callee code is generally smaller. For
    example, the wrapper function we all need to get an AddressOf value is often
    written with 'Function FuncAddr(pfn As Long) As Long', but 'Function
    FuncAddr(ByVal pfn As Long) As Long' generates significantly less code.

    -String types ByVal are nasty because of the deep copies. I offer some ways
    around this in my book (use StrPtr/As Long/StringRef structure to interpret
    the string and/or make a post-build typelib modification to make a method
    take a string instead of a long). This is magnitudes faster for long
    strings, but the benefits become less as the strings get smaller (although
    StrPtr/StringRef is faster than a ByVal string pass at around 30
    characters). The flip side here is that a constant string passed to a ByRef
    String must be copied before the call by the caller, although it is copied
    anyway by the callee if you pass it to a ByVal.

    -Object types. If the types are exactly the same, then ByRef is a big win
    (no AddRef/Release cycles). However, ByRef is absolutely miserable if you're
    doing an implicit type cast on the call. This is discussed extensively in
    Chapter 3 of my book.

    -Matt



  5. #5
    Bob O`Bob Guest

    Re: ByVal vs ByRef

    Matthew Curland wrote:

    > -String types ByVal are nasty because of the deep copies. I offer some ways
    > around this in my book (use StrPtr/As Long/StringRef structure to interpret
    > the string and/or make a post-build typelib modification to make a method
    > take a string instead of a long). This is magnitudes faster for long
    > strings, but the benefits become less as the strings get smaller (although
    > StrPtr/StringRef is faster than a ByVal string pass at around 30
    > characters). The flip side here is that a constant string passed to a ByRef
    > String must be copied before the call by the caller, although it is copied
    > anyway by the callee if you pass it to a ByVal.


    But a small amount of testing some time ago convinced me that even this
    "magnitudes faster" is pretty meaningless if the strings are read from
    and/or written to files.

    I recently wrote a CSV-to-XML converter in VBScript, which reads the
    input file into a string, parses the header, builds a converted XML string
    (using lots and lots of concatenation), then writes the XML to a file.
    All that concatenation is supposed to be dog-slow, but for a test,
    I replaced the entire conversion with a plain string copy, and for
    files under about 20MBytes, it was hard to tell the difference.

    Did I miss something?


    Bob O`Bob
    --

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center