Does using With .... End With speed up code any or is just to make
programming easier?

Thanks,
Ed

I did some speed tests on this (many years ago) and I found no difference in
speed. I use it because 1: It can cut down on lenght of a line of code. 2:
Cuts down a lot of window changes in the IDE when stepping through code with
Classes etc.
Hope this helps.

Ivar

On Mon, 9 Mar 2009 01:00:59 -0000, "Ivar"
<Ivar.ekstromer***@ntlworld.com> wrote:

I just use it because the code is neater.

MM

Ed wrote:
It depends on how and where it's used. If you use it to reduce object
depth by more than one dot, and apply to more than one property or
method, then it definitely helps speed.

I think VB will cache a temporary object when it can, doing the
equivalent of With..End on its own, but I never depend on that.

I use it liberally, on the theory that it never hurts, often helps,
and is easier to read and maintain.

I personally dislike the structure because it can make the code difficult to
read. My opinion is that the only purpose is to save typing. My guess is
that With blocks will be slower in an interpreted language like VBScript,
but you would be unable to measure the difference. In VB With blocks may
make the compilation a bit slower, but the compiler will optimize the code
regardless and affectively remove the With blocks, so there will be no
difference in the final module.

I once saw code where the With blocks spanned maybe 100 lines and were
nested. There was no way to troubleshoot it until I removed the With blocks.
This experience influenced my opinion.

<cut>
Any construct can be abused; that doesn't mean that it isn't useful when
used judiciously.

Yes <g>

There is a common myth that With blocks speed up your code. I proposed in
this group many years ago that With blocks are actually slower and a big
debate arose. All of those in the debate eventually agreed I was in fact
correct (well no one ever does that in a newsgroup but after seeing the
evidence they all quickly bailed). Since then the debate has arisen a few
times and we might even have another one now :-)

Just to example further, if you have code like this

A.B.C.D.DoSomething()
A.B.C.D.DoSomething()
A.B.C.D.DoSomething()
A.B.C.D.DoSomething()
A.B.C.D.DoSomething()

Michael

I don't remember such a debate, but then perhaps it was before the time I
first began to use this group myself. I can't see why everyone involved
would have eventually agreed that you are correct though, especially as you
are in fact wrong.

Much depends on exactly what you are doing, but With blocks in general are
in most cases at least as fast as the equivalent code without them, and
sometimes faster. Naturally it is possible to contrive a specific test that
uses a With Block in an unconventional manner which might produce a
different result, but in general they are at least as fast as code that does
not use them. They are certainly not in the general case slower, as you have
suggested.

By the way, why have you decided to stick your nose in here again in an
attempt to stir up a controversy. Is it because you are getting fed up with
the battering you have recently been taking in the VB.Net group?

Mike

   I think he was referring to the laws of that strange
village named DotNetVille, where everything needs to
be preceded by several objects in order to work. One
doesn't just mow the lawn in DotNetVille. It won't work.
Instead, one leverages the architected solution:

  toolshed.tools.summer.mower.mow("backyard")

on the solution:

  ElmStreet.house.number[23].property.grounds.greenery

  If that solution leverages the architects successfully then
of course it's the fastest, since no other architecturation
*can* work!

Show quote Hide quote I accidentally pushed ctrl-enter before I finished my previous post then
decided I was running too late to finish it. What I was going to say is that
if you have code like this

A.B.C.D.DoSomething1()
A.B.C.D.DoSomething2()
A.B.C.D.DoSomething3()
A.B.C.D.DoSomething4()
A.B.C.D.DoSomething5()
A.B.C.D.DoSomething6()

then doing

With A.B.C.D
    .DoSomething1()
    .DoSomething2()
    .DoSomething3()
    .DoSomething4()
    .DoSomething5()
    .DoSomething6()
End With

will of course be faster. But what idiot would write the first block of
code? Any programmer worth his salt is going to write

dim x as D
set x = A.B.C.D
x.DoSomething1() etc

Now if a programmer does this third block of code then it will actually be
faster than the block of code using the With statement. So basically With is
only faster than poorly written code but compared to well written code it is
actually slower.

Michael

Show quoteHide quote

Hi,

Michael C schrieb:

Show quoteHide quoteAh ja. This is a handcoded replacement of With. Which idiot would not
use the With shortcut in this case (which is a typical use case for With)?

Ulrich Korndoerfer wrote:
....
Show quoteHide quoteI've not actually checked, but it would seem quite likely both of these
would generate the same code.  It would seem quite unlikely to me there
should be any inherent speed advantage of one over the other.

"With" is a feature that is really "syntactical sugar".

Show quote Hide quote Not sure about that, I always understood (or possibly misunderstood) that
using "With/End With" only makes a single call to the COM while without the
construct there would be a call on each line.
Personally I like the With construct, especially for a nice full RecordSet.
I don't like nesting them because that looks too confusing.

Dave O.

Dave O. wrote:
Show quoteHide quoteThat would be dependent on the optimizer -- as I say I've not looked at
generated code but it surely isn't much of a stretch to think the code
generator would recognize the common object and convert the With
construct to the equivalent.  It's possible they never got around to
implementing such and the explicit reference helps the code generator
recognize the commonality it doesn't otherwise but it's so obvious it
just seems unlikely.

Of course, if I really gave a _insert_descriptive_noun_, I'd generate a
test case and look,  ( :) )

But unless I had an actual application and had profiling information
that proved it was a true processing bottleneck I'd take the code
clarity hands down.

Trust me I have checked and they don't.

With is most definately slower, it is a pretty small bit slower and it would
almost never matter in real life but it is slower.

I would describe it as syntactical bitter :-)

Michael

It's the other way around, With is a replacement of the object reference.

That's a different question, my point is With is slower than the object
reference. Personally I stopped using With after I was searching code for
rs.Open and couldn't find it.

Michael

Michael C schrieb:
Playing ping-pong?

In the case shown With is as fast as what you call "object reference".
And no, I will not show test results for you. I have tested With,
measured execution speeds and had a look to the generated code, all long
time ago. My results were clear and for the case in discussion say that
With is as fast as using one's own temp object reference.

And again no, With is not mere syntactic sugar. With causes the compiler
to create a hidden object variable to buffer all in front of the first
"." and to use it inside the With block. But of course any idiot may
take the same approach without using With.

No, that is my point, With is *slower*. It's not much slower but it is most
definately absolutely 100% positive NOT faster than using the object
reference.

No need, I have done it before and proved With to be slower.

Your results were incorrect then. The difference is pretty small so maybe
you didn't use a high enough resolution timer or perhaps your call to the
object was too expensive (eg Text.Text = "X") to show the difference.

I wouldn't call it sugar, more I would say it is a way to obfuscate code.

Michael

Hi all,

I share the opinion of Richard Mueller, I almost never use With because I
don't like it.

I performed a test with a very simple sample, and with the structure it
performs slightly faster, at least in this particular case (opposed to what
Michael C said that he tested, but I guess it must depend on the code).

To test it, start a new project, add a textbox and two command buttons, and
this code:

Private Sub Form_Load()
    Command1.Caption = "With"
    Command2.Caption = "No With"
End Sub

Private Sub Command1_Click()
    Dim c As Long
    Dim t1 As Variant
    Dim t2 As Variant

    t1 = Timer
    With Text1
        For c = 1 To 200000
            .Text = "AAA"
            .BackColor = vbRed
            .ForeColor = vbWhite
            .Text = "BBB"
            .BackColor = vbWhite
            .ForeColor = vbBlack
        Next c
    End With
    t2 = Timer
    MsgBox Int((t2 - t1) * 1000) / 1000
End Sub

Private Sub Command2_Click()
    Dim c As Long
    Dim t1 As Variant
    Dim t2 As Variant

    t1 = Timer
    For c = 1 To 200000
        Text1.Text = "AAA"
        Text1.BackColor = vbRed
        Text1.ForeColor = vbWhite
        Text1.Text = "BBB"
        Text1.BackColor = vbWhite
        Text1.ForeColor = vbBlack
    Next c
    t2 = Timer
    MsgBox Int((t2 - t1) * 1000) / 1000
End Sub

Show quote Hide quote Interesting, there is a slight speed difference.

Ed

Show quote Hide quote <code snipped>

Just for grins I too ran this sample, but added one more button ...

Private Sub Form_Load()
    Command1.Caption = "For Within With"
    Command2.Caption = "No With"
    Command3.Caption = "With Within For"
End Sub
....
Private Sub Command3_Click()
    Dim c As Long
    Dim t1 As Variant
    Dim t2 As Variant
    t1 = Timer
    For c = 1 To 200000
        With Text1
            .Text = "AAA"
            .BackColor = vbRed
            .ForeColor = vbWhite
            .Text = "BBB"
            .BackColor = vbWhite
            .ForeColor = vbBlack
        End With
    Next c
    t2 = Timer
    txtTime(2).Text = Int((t2 - t1) * 1000) / 1000
End Sub

The results averaged over 50 runs
                                 IDE / Native Compile / PCode / No
Optimization
"For Within With"       3.146 / 3.237 / 3.265 / 3.234
"No With"                   3.296 / 3.340 / 3.559 / 3.328
"With Within For"        3.197 / 3.265 / 3.312 / 3.265

In all cases the 'With...End With' produced a few clicks better performance.

If you examine the disassembled code, the difference in how it goes about
resolving "Text1".

It looks like the 'With...End With' construct does something like this ...
     With Text1
           ; Long tmp = TheResultOfDereferencing(Text1)
           tmp->Text = "AAA"
           ...
      End With

Such a construct would be consistent with the qualitative difference in the
results. But
I won't go any farther than that, because my days of understanding the
subtle difference in ASM are long behind me. lol

But again - this difference while real and supportive of the view the
construct does save a few clicks - the difference is so small to be
essentially meaningless in a real application.

Use when it helps to improve readibility, don't use it when it doesn't (or
when the pointy-haired boss tells you not to).

-ralph

According to Microsoft it should speed up code, but I did also find no
significant speed differences. But what I find more important -and that is
my main reason for not using With/End With, especially with nested With's-
is the following. Whenever a handled error occurs in a With/End With block,
and the program jumps to the err handler, the With counter will not be
reduced with 1 (because it did not encounter a End With). This often leads
to wrong memory readings in the next With/End With block and it will
(unnnecessary) destabilize Your program.

Yours friendly,

Hans Heezemans

----- Original Message -----
Newsgroups: microsoft.public.vb.general.discussion
Sent: Monday, March 09, 2009 1:43 AM
Subject: With .... End With - Speed


Show quoteHide quote

I would think if you Resume'd back into the With..End With block, things
would be fine. Jumping elsewhere would start to have the feeling of
"spaghetti code" to me. Another alternative to jumping to an error handling
label would be to use an On Error Resume Next construct and handle the error
inline.

By the way, for the purposes of this discussion thread I really LIKE the
With..End With block construct.

Show quoteHide quote

Not so handy in practice however.

First, You have to check if error originated from the With/End With block
and from outside it, which means writing extra code .

Second, not all error handling should continue with the following code line,
in some cases that just is unwanted.

Yours friendly,


Hans Heezemans

Show quoteHide quote

Show quote Hide quote lol

The reason you don't like the With...End With coding construct is because
you don't like the With...End With coding construct. Inventing complex
scenarios where it might be a problem is poor justification for avoiding it
career-wide.

We get this same responses to questions on other coding "short-cuts" such as
the Dictionary Lookup Operator (Bang!), colons, While...Wend, and comma
operators. All are essentially innocuous and can improve readibility. All
can be misapplied to reduce readibility or have an effect on later
maintenance. Banning any of them from your coding arsenal because of what
MIGHT happen or that they are not appropriate for ALL situations is IMHO
just plain silly.

If you're aware that a particular construct might be a problem for a
specific situation then don't use it. That's the kind of decision a
programmer makes everytime he/she touches the keyboard.

If you were not aware that a construct might be a problem it is highly
likely you will discover that fact soon enough. That's called learning. And
it is something else that happens everytime a programmer spends any time at
the keyboard.

-ralph

I can agree with that, I strongly dislike the With statement just because I
don't like it. It's interesting to see how the tide has turned as it appears
the majority here don't like it.

Michael

Count one more for the "like it" side; it may be that explicitly coding what
it does implicitly is even faster but IMO the With construct is the most
readable.

Agreed!

Show quote Hide quote There are times I use both the With and explicit coding but that's when I
have 2 or more objects that I need to reference often:

set temp=object1.prop1[x].prop2
with otherobject.someprop
  .myprop=temp.someprop
  .xyz=temp.abc
  temp.whatever=.final
end with
set temp=nothing

The 'With' block references whatever is used most often or is the focus of
the code.  I guess that's whay they call coding an art and not a science.

Show quote Hide quote And that is what I do as well.

One of the definitions of 'art' is the production or arrangement of elements
to produce an emotional response from a viewer.

With...End With has certainly demonstrated its usefulness in generating
emotion responses.

-ralph

Show quote Hide quote I like it as well. Keep in mind that the timing tests are being done with machines that
are faster than when the language feature was first implemented.

-mhd

The timing is certainly NOT a factor. The difference is minor and not a
reason to avoid With. I just avoid it because it's ugly.

Michael

I use it when it makes sense to use it....

LFS

You are jumping to conclusions.

I used to use With/End With a lot since it was recommended by MS (it would
speed up code, produce better readible code and most important I needed to
type less code).

However when an error occured in some With/End With blocks, users of my
applications could not use it anymore even after closing and restarting it.
The only solution was to restart Windows.

After adapting the With/End With blocks I ended up with a lot of extra,
difficult to mantain code. So I removed the With/End With blocks in these
places.

The result has been that my apps don't have the above mentioned problems
anymore and there has been no loss of speed. I also find code without
With/End With easier to read and easier to maintain.

If that is silly to You OK (in that case I would say You're silly), for me
it is not because it has been and still is valuable not to use With/End
With.

Yours friendly,


Hans Heezemans

Show quoteHide quote

You are absolutely just in your opinion.

If one has been fightened by a dog and therefore chooses to no longer have
any dealings with dogs - then that is fine. As contrary to popular opinion
one can live a long and fruitful life without dogs in their lives.

The only question is the validity of using that one bad experience as
justification to suggest that no one else allow dogs in their lives either.

[Of course if that dog was a pit bull you would likely find more agreement,
but With...End With isn't a pit bull, just a plain working shepherd.]

-ralph

I am sorry, but I opt for 100% reliablity if possible. I just want an
application that will function without any problem at all times. I do not
have an obsessive fear for using With/End With constructs.

The only point I wanted to make is that
a) in my experience there is no signaficant speed gain in using With/End
With constructs
b) not unimportant in considering to use the With/End With are some
drawbacks, of which I find the pointer issue, when an error inside a
With/End With has to be handled  by an err handler outiside the With/End
With scope, the most important.

That's all.

Yours friendly,


Hans Heezemans


Show quoteHide quote

Are you sure about this? You're saying there is a ref count bug with the
With statement? I thought it kept the ref count just fine, it just doesn't
decrement it until the function finishes. I just tested and it appears to
work fine to me. This is really expected behaviour I would have thought.

Michael

Hi,

Hans schrieb:

No. It doesn't do such weird things. Error handling in With...End With
blocks just works.

And, if you would think twice, the most rock stable part of VB is to
clean up *any* object references when a method leaves. With blocks
create temp vars on the stack holding object refs. If VB would not be
able to deref such objects, oh my.

And, there is no With Counter.

And again, any proofs?

It's to make writing your program easier and reading it more difficult ;-)

As far as speed is concerned a lot depends on how you use it and what you
use it for. If, for example, you are using it with a nested member of a UDT
and if you run your code as a native code compiled exe you'll find that in
general there is no difference in speed whether you use With / End With or
not. However, if you perform the same test when running in the IDE or when
running as a PCode compiled exe you will find that using With / End With is
a little slower, because of the extra work needed for VB to analyse the
PCode. So, if you are going to end up compiling your project to native code
and if you are using With / End With in this specific way then it will make
no difference to the speed whether you use it or not.

Conversely, if you are using With / End With on nested property of an
Control (for example Text.Container.Left = 99) then you'll find that using
With / End With is faster in all cases (IDE, pcode and native code).

With real world code of course (as opposed to artificially contrived speed
tests) there won't be a great deal of difference either way because in most
code there is a lot of stuff within the With / End With block that does not
actually use it.

Personally I often use With / End With in short to medium sized blocks of
code to save myself some typing, and sometimes to make it easier for me to
change things while I am developing some code, but for large blocks,
especially if you have lots of nested With / End With blocks, it can make
your code very difficult to read and so in such cases I generally avoid it.
As with most things, it's horses for courses :-)

Mike

We agree on something :-)

Wrong, it is slower than

Dim x as Contain
set x = Text.Container
x.Left = 99

Michael

If I do Dim x as Object then it runs at exactly the same speed as the With /
End With construct. To get it to run faster I need to hard code the type of
object (Dim x as PictureBox or Dim x as Frame or Dim x as Form or whatever
depending on the type of container, which I might not know at the time of
writing my code). How can I work around that one? Also, it doesn't seem to
work at all with UDTs, and it doesn't seem to have made the code any more
readable either.

Mike

If With knows the object type then you can find it out easily yourself.

Probably not although you can pass a branch of a UDT into a function to get
high speed access to it.

That's debatable and a matter of opinion.

Michael

But that won't produce any speed increase, in fact it is likely to slow it
down. Besides, you've just said yourself that timing is not a factor and any
difference is minimal and that you avoid With simply because you believe it
to be ugly. Are you seriously suggesting that passing a branch of a UDT to a
function as a replacement for using a simple With / End With construct will
make your code more readable? Surely not.

Mike

That is correct. The reason I say With is slower is not because I believe it
should be avoided for speed reasons. I'm just dispelling the myth that it is
faster.

From what you say With is not faster with UDTs? That leaves the only option
for an increase in speed to be a function. I was under the impression that
this did make it faster but am not certain. Are you saying there is no speed
increase?

Show quoteHide quote

What I am saying is that, in common with many things of this kind, the
answer you get when you perform a speed test will depend to a great extent
on the answer you want it to provide!

It would for example be very easy to knock up a speed test that passed a
deeply nested member of a UDT to a function by reference and have that
function perform a loop incrementing the value by one (or whatever else you
wish to do) many times within the loop inside the function. In that case,
since the function has a nice clean pointer to the location of the item, you
are likely to find it faster than using a With / End With construct to do
exactly the same thing (incrementing a deeply nested member of a UDT many
times in a loop).

However, that is not what With / End With constructs are usually used for.
Generally there are many statements within the construct, some of which
operate on the item referenced by the With statemnt and some of which do
not, and in the general case each time such an item is referenced it is
acted upon just once in that line, with the rest of the construct going on
to execute further statements until it comes to another member (perhaps a
different member) of the item referenced by the With statement, and it acts
upon that item just once, and so on and so on. To simulate such a construct
using your own suggested method of passing the parameter to a function then
you would need to call that function once for every different member of the
referenced item, operating upon that member just once, or perhaps just a few
times, each time and once for each time you individually addressed a
specific item. In such a real world case that method would execute slower
than the standard With / End With construct because of the overhead of
calling the function.

As I often say, it's horses for courses and in most real world applications
there is nothing whatsoever to be gained from following your suggestion, and
it certainly doe not add to the readability of the code, especially since in
most real world implementations of a typical With / End With loop you would
need to passd the function a lot more than just the item you wanted it to
act on. That's not to say its not a good suggestion of course. In fact in
some cases it will be extremely useful, but my own opinion is that in the
genaral case it will not and that, as long as the block is not excessively
long and nested, a With / End With construct is a neat and quick method that
works very well and is very readable. Naturally it becomes less readable as
its size and nesting grows larger and deeper, but then so does the method
you have advised.

Mike

Show quote Hide quote It's just better to avoid complex UDTs at all imo. The VB compiler has a
real problem with them, try compiling the code below. While it's obviously
not something you would write in real life, the reason I wrote this code was
because an app was taking a long time to compile and using a lot of memory.
This just demonstrated the problem by exaggerating it a little.

Option Explicit

Private Type B
A() As Long
End Type
Private Type C
B() As B
End Type
Private Type D
C() As C
End Type
Private Type E
D() As D
End Type
Private Type F
E() As E
End Type
Private Type G
F() As F
End Type

Private Sub Form_Load()
Dim H() As G
ReDim H(0)
ReDim H(0).F(0)
ReDim H(0).F(0).E(0)
ReDim H(0).F(0).E(0).D(0)
ReDim H(0).F(0).E(0).D(0).C(0)
ReDim H(0).F(0).E(0).D(0).C(0).B(0)
ReDim H(0).F(0).E(0).D(0).C(0).B(0).A(0)
H(0).F(0).E(0).D(0).C(0).B(0).A(0) = 1
End Sub


Show quoteHide quote

You're duckin' and divin', Michael! First you were moaning about With / End
With and now you are moaning about UDTs and you are providing your very own
deliberately exaggerated examples of their (mis)use and you are pretending
that people here have suggested that it is a good idea to use them in such a
manner when in fact they have not done so at all. The subject of UDTs of any
kind was brought up specifically to illustrate a point regarding your own
initial suggested replacement method for With / End With with regards to
speed of execution. Nobody here has suggested that you should use massively
nested complex UDTs of the kind you have posted yourself, although I will
add that UDTs in themselves, when used sensibly, are not a problem at all.
In fact they are extremely useful. So stop trying to put your own
suggestions into people's heads simply so that you can pretend that they
suggested it themselves and argue against them. Obviously arguments turn you
on Michael (perhaps its the feeling of loneliness and disconnection from the
rest of the world out there in the wide open arid wastes of Australia), but
you prefer to argue when you have the safety net of an argument for which
you sowed the seeds yourself and which you have already researched and
rehearsed. As I have said, nobody here has suggested that you should use the
heavily nested complex UDTs of the kind that you have posted yourself. You
are attempting to put the idea of using them into somebody else's head so
that you can then argue against it. You are duckin' and divin' and looking
for an argument of your own manufacture. Please go and argue somewhere else
because you really have no legitimate business here and you are seriously
beginning to bore me to the point where I think I shall just totally ignore
you in future. Having said that, I shall use the With / End With construct
and I shall use UDTs as and when I see fit, and in the manner I see fit, and
you can do whatever you wish to do. I repeat, you have no legitimate
business here Michael, so please go away and play in your sheep dip with
your friend and neighbour McCarthy.

Mike

Show quote Hide quote Way too much text mike. Try saying what you're trying to say in a reasonable
number of words. Possibly if everyone looks like they're ducking and diving
then maybe you're trying to pin something on peple that isn't there.

Michael

I thought it makes code run faster when the number of dots are reduced and
this makes sense.
Not tested it though.

RBS


Show quoteHide quote

RB Smissaert wrote:
With late-bound objects, absolutely.  The difference can be substantial.

With early-bound objects, its unlikely to be measurable even if detectable in a
disassembly.

I read that the main reason to use With End With,
is that End With destroys the object.

Is that not the case?

Show quote Hide quote No, the object can still be used after the End With statement.

Show quote Hide quote No. I guess that you could read that it makes a temporary *reference* to the
object in the With statement, and destroys it in the End With.

Show quote Hide quote No it is not the case.

There is very little magic going on with 'With...End With'. It is a coding
construct that was added to the language to help reduce repetitive typing
and aid in readibility. The authors provided it mostly because, like so many
*extra* features in any product, they could.

Although code written using 'With...End With' is a few clicks quicker, it is
on a scale to make it almost immeasurable. So I wouldn't bother considering
it as a 'performance booster'. Use it when it makes sense to improve
readibility or maintenance. Avoid it where it might have the opposite
effect.

-ralph

On Mon, 9 Mar 2009 22:11:07 -0500, Ralph wrote:

Yes it is, under certain circumstances ... ;-)

Example:

  With New cMyClass    ' <- Object is created here
    .DoSomething
  End With             ' <- Object is destroyed here


Wolfgang

Show quote Hide quote I was sort of waiting for that one. ha

Other interesting abuses (? <smile>) of  With...End With include creating a
class with a default that returns a reference to itself or function that
returns an instance of another object.

Playing with Collections of Objects that return Collections/Arrays of
Objects with nested With...End With statements and the Bang operator can be
equally fun, as well as guaranteed to extremely annoy someone. lol

-ralph

Public Thank You To Microsoft
Wrap a Long String
Number Puzzle
vb6 closes with erro after I installed msdn oct 2001
Subclassing a la Caton
Does anybody know how to translate this C# code to VB6?
Control Container Property - Why Use It?
VSM Wants Your Feedback
Need a Friend, Maybe
Which is the Best Twain ActiveX?