Printable View
Is there any advantage to doing this:
instead of this:Code:With Object
.Blah = 100
.Thing = 20
.SomeOtherNumber = 5
End With
Apart from, of course, being neater, does using With give any other advantages? e.g. speed (efficiency) etc.Code:Object.Blah = 100
Object.Thing = 20
Object.SomeOtherNumber = 5
I was under the impression that the WITH clause resolves the memory address of the object once - so that speed is increased.
Althought this link I googled for seems to say otherwise...
http://c2.com/cgi/wiki?WithBlockCodeSmell
One advantage only - code becomes much more readable (perhaps one more - less typing ... ;) ).
With is faster than doing it the other way. I tested it before and got a dramatic speed increase.
Please don't make me have to do another performance test to prove it. Trust me, it's faster. ;)
Typing Object.whatever over and over. Where as in With, you don't tyoe Object. ;)
That's what I mean. There I edited my above post. :bigyello:
I'm afraid you're wrong: when With - End With is used compiler has to evaluate property and "decide" to which object it (property) belongs to ... as you may have nested With (sample below) so having Object.Property will actually speed it up but code itself becomes a bit redundant.
VB Code:
I think we can all agree that the WITH block makes the code easier to read.
Although the link I showed in post #2 says it will cause you programming problems later in the routine (I don't agree with this myself).
I've have read that every "dot" slows down execution...
I believe I read that in the MS VB Reference Books - in the "optimizing code appendixes" (books at office at work - can't verify this).
Maybe a WITH clause with a multi-dot reference is faster.
Thanks for the responses guys :thumb:
I might do a performance test myself. If I get some results I'll post them back here.
One would think, if With sets up a a memory reference, that a With block would be faster than a non-with block. But we'll see, if I get the test done.
If you do a test - make sure it's with a multi-dot object...
Like a LISTVIEW.SELECTEDITEM.SUBITEM() or some TREE VIEW deep down sub object...
Well I'll be damned. Take a look at this:
VB Code:
Is that in ms? If so, that looks like a slight win for the With block.Quote:
Originally Posted by Jacob Roman
Well here are the results I got. I went with szlamany's suggestion of a listview subitem thing (and because it is very early morning I probably coded it all wrong :p )
And the test code was:Code:Results averaged over 4 runs each at
normal thread priority
With Block Dot Reference
IDE 129 ms 578 ms
EXE 106 ms 613 ms
Code:Option Explicit
Private Declare Function GetTickCount Lib "kernel32" () As Long
'
Private Sub Form_Load()
ListView1.ListItems.Add 1, "Thing", "Thing"
ListView1.ListItems.Item(1).SubItems(1) = "blah"
End Sub
Private Sub Command1_Click()
Dim lngStartTime As Long
Dim lngTotalTime As Long
Dim lngTimeAvg As Long
Dim lngCount As Long
Dim lngLoopCount As Long
LoopDotRefStart:
lngCount = 0
lngStartTime = GetTickCount()
Do
ListView1.ListItems(1).SubItems(1) = lngCount
lngCount = lngCount + 1
Loop Until lngCount = 100000
lngTotalTime = lngTotalTime + (GetTickCount() - lngStartTime)
lngLoopCount = lngLoopCount + 1
If (lngLoopCount < 5) Then GoTo LoopDotRefStart
lngTimeAvg = lngTotalTime / 4
Text1.Text = "Dot reference (4x): " & lngTimeAvg & "ms"
lngTotalTime = 0
lngLoopCount = 0
With ListView1.ListItems(1)
LoopWithBlockStart:
lngCount = 0
lngStartTime = GetTickCount()
Do
.SubItems(1) = lngCount
lngCount = lngCount + 1
Loop Until lngCount = 100000
lngTotalTime = lngTotalTime + (GetTickCount() - lngStartTime)
lngLoopCount = lngLoopCount + 1
If (lngLoopCount < 5) Then GoTo LoopWithBlockStart
End With
lngTimeAvg = lngTotalTime / 4
Text1.Text = Text1.Text & vbCrLf & "With block (4x): " & lngTimeAvg & "ms"
End Sub
Great thread :thumb: I also remember reading that the dots reduce performance.
Nice performance testing guys. This makes me wonder how OOP relates to performance since its all
object dot object dot blah, blah, blah..., but since its object oriented that probably makes the difference.
Penagate:
Don't have time to play with myselft BUT
you might also want to try running your example using an object variable in lieu of the object itself. I think "With" will still be faster.
For example:
Instead of:
Code:ListView1.ListItems.Item(1).SubItems(1) = "blah"
Use:
Code:Dim objLV as ListView
objLV.ListItems.Item(1).SubItems(1) = "blah"
You can enhance that even farther.
VB Code:
LOL ... you may want to refrase that ... :p :p :p :wave:Quote:
Originally Posted by dw85745
No the other one won. With is slightly slower. That's how many times per second it was executed. ;)Quote:
Originally Posted by penagate
JR, Penagate's test shows the amount of time to performa 100000 loops so its opposite results from yours?
See for yourself
JR, looks like yours shows that with is slower.
Guess if performance is not an issue I say go with the With block for easier reading. ;)
Didnt think it was fair to make the decision without testing Penagates code.
His shows the opposite.
So, final conclusion is if performance is an issue, Do more testing. Otherwise use the With block for easier reading. :p
RhinoBull:
Made it back. Just read your comment. Had to LOL at myself as didn't get double meaning at first read.
--------------------------
RobDog888
Setting object variable OR object = Nothing serves NO purpose. If I can track down article will post here. When Sub/Function exits, stack is cleared and all variable objects are also automatically cleared. Use to do (= Nothing) but stopped, and SO far no issues.
David
David,
you may want to reconsider your habits (or technics if you will). Stack isn't alwys gets cleared up especially when procedure has Static vars declared so explicitly resetting all object vars is really somthing you want to do without exceptions.
Wow! This is a very dangerous statement, even if it's basically true. VB will clear the stack memory when a procedure ends however assuming that the statement is always true will cause problems. If you for example use ADO and open a connection or recordset object and just leave it open when the procedure ends you can not for sure say that the RDBMS will close the connection properly and you might end up with corrupted data.Quote:
Originally Posted by dw85745
Also if you would port part of your code to a classic ASP page and still use the same approach, IIS will not clear the memory used by an object until the session ends. So you should always set your object references to Nothing when you don't need them anymore.
David, it is just good programming practice to explictly destroy your objects because, like just posted, there are
instances where the object will not get destroyed, even sometimes after your program is terminated. When doing
Office automation, especialy, you ALWAYS need to destroy objects explictly.
When programming with COM object you always run the risk of leaving objects in memory if they are not destroyed. ;)
I need to change my statement above.... IIS will never remove your object from memory unless you do it yourself. It will stay there forever, or until the web services has been stoped and restarted... unless you destroy the object yourself by setting it to Nothing.
Now that I'm fully awake :D
There a few possible reasons why JR's code gets different results from mine:
- I used a variable within an object within a ListView object, JR used a variable within a Type
- I put my code in a form, JR's in a module
- My With block was excluded from the loop, JR's was included
The last point has actually a fairly significant impact on performance. If you place the With and End With statements outside the loop, the performance is dramatically increased compared to when they are placed inside the loop.
So I tested it with JR's code, and these are the results I got:
You can see both in the IDE and compiled to native code (with full optimisations - JR what were you doing compiling to Pcode :eek: ) - Using With (and leaving the With/End With statements outside the loop) is slightly faster. Including the statements in the loop makes it definitely slower than not using a With block, because I suppose the the memory address is being resolved every time. If the contents of the loop were a lot longer then the results would probably be different.Code:High thread priority
Including Excluding Dot
statements statements reference
IDE 1,783,981 2,043,114 2,036,235
EXE 3,590,492 4,081,684 3,974,999
So Mr Roman, it would seem your code supports my results just as conclusively as my own :D
szlamany makes a good point that maybe the book was referring to multi dot objects.
Hey szlamany, if you can find that reference about the dots please post it. :thumb:
I don't find it's any easier to read the With format than a series of Object. assignments. The opposite if anything *shrug*
It's not very conclusive - but here it is...Quote:
Originally Posted by RobDog888
From page 774-776 of the MS Visual Basic 6.0 Programmer Guide - chapter 15 "Designing for Performance and Compatibility":
I also found the same info on MSDN site - here's the link (where I did the copy/paste from!):Quote:
When referencing other applications' objects from Visual Basic, you use the dot syntax "." to navigate an objects hierarchy of collections, objects, properties, and methods. It is not uncommon to create very lengthy navigation strings. For example:
' Refers to cell A1 on Sheet1 in the first workbook
' of an Microsoft Excel spreadsheet.
Application.Workbooks.Item(1).Worksheets.Item_
("Sheet1").Cells.Item(1,1)
In addition to being a rather lengthy string to type, this line of code is fairly difficult to read — and it is extremely inefficient.
When calling an object from Visual Basic, each "dot" requires Visual Basic to make multiple calls.
To write the most efficient applications, minimize the use of dots when referencing an object.
You can usually minimize the dots by analyzing the objects and methods available to you. For example, the above line of code can be shortened by removing the Item method (this is the default method for collections anyway, so youll rarely use it in code) and by using the more efficient Range method:
' Refers to cell A1 on Sheet1 in the first workbook
' of an Microsoft Excel spreadsheet.
Application.Workbooks(1).Worksheets("Sheet1")_
.Range("A1")
You can shorten this even further by rewriting the code so that it refers to the active sheet in the active workbook, instead of a specific sheet in a specific workbook:
' Refers to cell A1 on the active sheet in the
' active workbook.
Range("A1")
Of course, the above example assumes its OK to refer to cell A1 of any sheet that happens to be active.
Use Set and With...End With
Using the Set statement also allows you to shorten navigation strings and gives you a bit more control over your code. The following example uses the Dim and Set statements to create variables that refer to frequently used objects:
Dim xlRange As Object
Set xlRange = Application.ActiveSheet.Cells(1,1)
xlRange.Font.Bold = True
xlRange.Width = 40
Visual Basic provides the With...End With construct to set an implied object within code:
With Application.ActiveSheet.Cells(1,1)
.Font.Bold = True
.Width = 40
End With
http://msdn.microsoft.com/library/de...ingobjects.asp
It mentions mostly that a "dot" represents a series of calls to resolve the object at that dot. That makes sense.
I think what I can take away from this is that not all objects will behave the same way - some might be simply memory locations that need to be resolved - some might be more complex (EXCEL OLE - stuff like that).
I think that using WITH (or SET as RobDog mention) for both readability and possible better performance is a good idea - a good habit to get into.
Thanks for that szlamany, some interesting info there.
The conclusion we can draw from this thread :thumb: however conclusive/inconclusive the results of the performance tests :DQuote:
Originally Posted by szlamany
For those interested regarding the "Nothing" issue, this is the link to one of the articles I read making a case against the use of "Nothing".
RobDog88 and Joacim Andersson both make some good points for its use. My experience to date by eliminating "Nothing" has YET to cause an error.
http://www.keysound.com/html/ch_15_m...ut_nothing.htm
David
-----------------------
Tried above link and had problems, link has now been corrected. I should also clarify my point to mean "the blanket use of Nothing" rather than using it selectively -- see discussion in link.
Quote:
Originally Posted by dw85745
DW - that link has some garbage in it - you might want to clean it up...
I still managed to get to the site anyway :)
DW - that was a really good read - thanks for the info.
I particularly liked the info on circular references - probably the major reason for what people like to call memory leaks, which are really redundant uses of memory from poor event coding logic in the first place (really memory abuse!).
Your welcome szlamany. You may wish to read his other chapters (see site).
Has some very interesting comments as relates to VB.
My point was that habits are hard to kill. Just because VB kills the reference and therefor decrease the reference count in the object doesn't mean all environments does. One of the main problems with running classic ASP on IIS is that the number of objects created are always increased and never destroyed unless you would restart the web services. This would be easily avoided if developers would remember to set their references to nothing but alas VB has tought us that this is not necassary so people never get into this habit.
Yes, it was a good read but I dont 100% agree with him for a few reasons.
First, his experience is archaic. Windows 95 was his latest working enviroment. What, no experience
with 98/2000/XP. Come on get into the 21st century.
He doent have any experience with VB6? :lol: Things changed allot from VB3, 4, and 5. I mean come on,
upgrade so you can get with the same program as the majority of the users.
Second, he does not cover other scenerios other then the basic Standard Exe apps and does not discuss anything
complex. We are not writting "Hello World" programs, are we?
Third, he does not include COM and barely mentions ActiveX.
Yes, the guy know some stuff, but I mean come on. He may have been in the industry back in the day, but he's a
social worker or something like that now!
From that page I thought so as well, but in the foreword he mentions:Quote:
Originally Posted by RobDog888
Though again, it's by a different writer whom the main one asked to write the introduction. I suppose it was written before the rest of the book, so by the time it was published, .Net was probably already out...Quote:
Since then I've been working with Microsoft on every cut of Visual Basic, up to and including VB.Net (in Beta 2 at the time of writing).
Go figure! :afrog:
True, but either way I feel its a bit outdated and needs a definate update. VS.NET beta 2 was still years
ago and its a horse of a different color. VS has a GarbageCollector object that cleans up objects so if you
miss destroying some you can call the collection and poof, your clean. Nothing like VB6!
I couldn't help but contribute as this thread is now referenced from another thread that I followed to here . . .
set obj=nothing
. . .does not release the reference to an object. It calls the Release function on the IUnknown interface to which is bound. If you recall IDispatch is a superset of IUnknown. It also marks the local object as 'Nothing' for VB's type checking.
If the object is NOT nothing and the object is local to a function then VB will automatically decrement using the IUnknown.Release function as part of the End Function memory management (it will release memory used by other data-types, too)
When the object itself reaches a usage count of zero, the object itself destroys itself. There are no mechanisms (apart from zero'ing the objects memory) where VB can control lifetime of an object apart from incrementing or decrementing using the IUnknown interface using AddRef,and Release, respectively.
With Block
The with block creates a temporary object which points to the relevant IUnknowninterface of which you declare just after the With. So With MyObj.Child.Leaf will create a temporary object of type Leaf and will operate directly on the temporary object. This is safe to do as VB uses a reference scheme and no absolute memory copying. You can mimic the performance effect by doing the same - declare an object of type Leaf, and perform actions directly upon it will effect the parent MyObj's Leaf object too. You can verify this my checking the ObjPtr return value of MyObj.Child.Leaf, and the temp Leaf object. Be careful to grab the default interface, and not the IUnknown one as ObjPtr returns the reference to the interface and NOT to the object itself (so objects with multiple interfaces will need to be discerned using TypeOf)
Hope this adds a little . . .