Results 1 to 12 of 12
  1. #1
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Does this really run faster? (VB/VBA)

    This week's issue of the WordTips e-mail newsletter devotes some space to the suggestion that code execution can be speeded up by putting multiple statements per line.
    So for example:

    <pre>Sub PrevFind()
    With Selection.Find
    .ClearFormatting
    .Forward = False
    .Wrap = wdFindAsk
    .Execute
    End With
    End Sub
    </pre>

    might be done as:
    <pre>Sub PrevFind()
    With Selection.Find
    .ClearFormatting: .Forward = False: .Wrap = wdFindAsk: .Execute
    End With: End Sub
    </pre>

    The explanation given is that the compiler grabs code one line at a time, having more statements per line means fewer lines so code executes faster.
    (There is of course discussion of the tradeoff between increased speed and legibility of the code for the developer.)

    Not sure how much credence to give this, but would be interested to hear views. - Anyone situated to test this?

    Gary

  2. #2
    5 Star Lounger
    Join Date
    Dec 2000
    Location
    Reading/Swindon, Berkshire, United Kingdom
    Posts
    664
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Does this really run faster? (VB/VBA)

    Sitting here waiting for a database to come up so I've run the following code:

    Sub test()

    starttime = Timer

    x = 1
    Do
    With Selection.Find
    .ClearFormatting
    .Forward = False
    .Wrap = wdFindAsk
    .Execute
    End With
    x = x + 1
    Loop Until x = 10000

    Debug.Print Timer - starttime

    starttime = Timer

    x = 1
    Do
    With Selection.Find: .ClearFormatting: .Forward = False: .Wrap = wdFindAsk: .Execute: End With
    x = x + 1
    Loop Until x = 10000

    Debug.Print Timer - starttime


    End Sub


    and the data returned is as follows:


    <table border=1><td>x</td><td>1st</td><td>2nd</td><td>10</td><td>1.953125E-02</td><td>1.953125E-02</td><td>10</td><td>1.953125E-02</td><td>1.953125E-02</td><td>10</td><td>1.953125E-02</td><td>1.171875E-02</td><td>100</td><td>0.1992188</td><td>0.2226563 </td><td>100</td><td>0.28125</td><td>0.2109375</td><td>1000</td><td>2.023438</td><td>2.003906</td><td>1000</td><td>2.011719</td><td>2.003906</td><td>1000</td><td>2.054688</td><td>1.992188</td><td>10000</td><td>24.49609</td><td>23.5625</td><td>10000</td><td>21.50781</td><td>21.24219</td><td>10000</td><td>21.07031</td><td>19.62109</td></table>

    I'm not sure what that proves (note that when the loop was only 10, the second evaluation took longer - a result which happened more than once), and all this was done uncompiled and without option explicit. Also, I think I've seen something by Chip Pearson saying that doing this doesn't mean anything in terms of speed - I'm off to try to find that link now.

  3. #3
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts

    Re: Does this really run faster? (VB/VBA)

    I also did some testing.
    1. <LI>In Excel (97), I did some calculations involving several worksheet functions and mathematical operations. I created a version with each statement on a separate line, and a version with all statements on one line.
      I called each procedure 300,000 times in a loop and timed both. Both executed in about 81 seconds. The one-line version was about 0.1seconds faster. Although this was consistent, this doesn't justify the loss of readability.
      <LI>In Access (97), I had an existing procedure using DAO to loop through a table with about 50,000 records and using info from this to add some 200,000 records to another table. I made a copy of this procedure and put as many statements in the loop part on one line as I could. I timed both. Both executed in about 89 seconds, with a 1 second advantage for the one-line version. Again, the difference doesn't amount to much.
    So from these tests, I'd say it isn't worth bothering with. I'd rather keep my code readable.

  4. #4
    Gold Lounger
    Join Date
    Dec 2000
    Location
    New Hampshire, USA
    Posts
    3,386
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Does this really run faster? (VB/VBA)

    I haven't tested, but reasonable compiler/interpreter implementations do not "Read" a line at a time.

    In addition, having multiple statements per line has to take time to break up the line into separate statements.

    Putting multiple statements on a line is useful for code obfuscation, but not much else.

  5. #5
    4 Star Lounger
    Join Date
    Dec 2000
    Location
    Faifax, Virginia, USA
    Posts
    542
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Does this really run faster? (VB/VBA)

    Why wonder when you can measure? That's why I wrote Meter for vba. (see my .sig)

  6. #6
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Does this really run faster? (VB/VBA)

    Peter,

    The next time I need to do an important measurement, I will check out your VBA Meter (I promise!).

    In this case due to a combination of laziness and lack of time, I was hoping someone else might have a handy setup to give the idea a spin - I'm thankful to Brooke and Hans for having done so.

    Their results appear to confirm one's intuitive sense, along the lines of Howard's comments, that a statement to interpret is a statement to interpret; it don't matter (much anyway) how many lines it's on!

    Just my opinion, but some of the VBA tips in the WordTips newsletter just make me scratch my head, and this one only reinforces that opinion! <img src=/S/grin.gif border=0 alt=grin width=15 height=15>

    Gary

  7. #7
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Does this really run faster? (VB/VBA)

    Ah, but multiple statements in a line look so much more abstruse and esoteric, so the person who writes them that way must be a real pro, right? <img src=/S/laugh.gif border=0 alt=laugh width=15 height=15> I'll take readability over impressiveness any day!
    Charlotte

  8. #8
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Does this really run faster? (VB/VBA)

    How To Write Unmaintainable Code - happy reading! <img src=/S/laugh.gif border=0 alt=laugh width=15 height=15>

  9. #9
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: Does this really run faster? (VB/VBA)

    Ahhh, but would it run faster if you use the Execute method with all those other settings as parameters? <img src=/S/wink.gif border=0 alt=wink width=15 height=15>

    (Running away, way too late to instrument that!)

  10. #10
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Does this really run faster? (VB/VBA)

    Too late for me to test it either, but I'd say in that particular special case "probably would".

    But that is coincidentally just a special case as there aren't too many other methods in Word VBA like Find.Execute where you have the option of calling them like a function with parameters. Still, a <img src=/S/clever.gif border=0 alt=clever width=15 height=15> for mentioning it.

  11. #11
    Gold Lounger
    Join Date
    Dec 2000
    Location
    New Hampshire, USA
    Posts
    3,386
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Does this really run faster? (VB/VBA)

    In any reasonable implementation, Yes, it would run faster putting the parameters on the .Execute line.

  12. #12
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Does this really run faster? (VB/VBA)

    > the compiler grabs code one line at a time

    In a word : CRUD

    If you've ever had a syntax error in a Global template you've had that message along the lines of "Compile error in Hidden module".

    What other explanation for that can there be than this: That at the instant the template became available to VB, it parsed the entire template - "tokenisng" it's called - and I've made posts about it before. The VB scans the source and converts all the source into a series of tokens, a language more coded than VBA source and not as coded as machine code.

    That means that the template source code is scanned but once, up front, not repeatedly. Hence syntax errors are reported at load-time, not at run-time.

    Any timing runs will likely show insignificant discrepancies (as currently reported already, I see).

    Timing runs WOULD be of interest comparing the execution of two copies of a template, the second template having had all comments and white space stripped out a la Payne Consulting. I would expect SLIGHTLY faster loading of a payned job than a plain source, and again, no difference in execution time amongst the four combinations (Payne/not Payne).(Colons/No Colons). There's a jood joke in there about a colon in the payne. I'll see if I can work it out.


    This too: Remember that Tuesday morning early this millenium when I questioned the number of global templates and loaded Word97 with 255 templates in my startup directory? I reported back on THAT late Wednesday night after Word had finished loading (grin) more evidence of the challenging processing going on ("tokenising") up front at the time the templates are loaded.


    BTW, CRUD refers not to you, but to the source of your info. Confusion Really Undermines Developers.


    Another clue lies in the weird and un-informative messages supplied FREE (you gets what you pays for). Next time you're puzzled by such a message, ask "Is this coming from tokenised code?" It's why, I expect, VB can't/doesn't report useful stuff such as line numbers etc at run-time.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •