Creating Objects and Performance 
Author Message
 Creating Objects and Performance

I was reading not to long ago a posting and the person that wrote it
mentioned that there was a "good" way and a "bad" way to instatiate an
object. One way caused the compiler to check each time the object was
referenced to see if it had been set yet.  The other the compiler
knew.  I think as an example.

Right way

Dim x as new obj.class

for i = 1 to ubound(t)
  x.Days = x.Days + 1     'Compiler knows it has reference, no extra
work
next

Wrong way

Dim x as obj.Class
Set x = new obj.class

for i = 1 to ubound(t)
  x.Days = x.Days + 1     'Compiler has to check reference has been
set.
next

Can someone confirm/correct that?

Thanks
Jeff



Tue, 26 Oct 2004 02:11:24 GMT  
 Creating Objects and Performance
You've got the right and wrong ways backwards.
Quote:

> I was reading not to long ago a posting and the person that wrote it
> mentioned that there was a "good" way and a "bad" way to instatiate an
> object. One way caused the compiler to check each time the object was
> referenced to see if it had been set yet.  The other the compiler
> knew.  I think as an example.

> Right way

> Dim x as new obj.class

> for i = 1 to ubound(t)
>   x.Days = x.Days + 1     'Compiler knows it has reference, no extra
> work
> next

> Wrong way

> Dim x as obj.Class
> Set x = new obj.class

> for i = 1 to ubound(t)
>   x.Days = x.Days + 1     'Compiler has to check reference has been
> set.
> next

> Can someone confirm/correct that?

> Thanks
> Jeff



Tue, 26 Oct 2004 02:34:28 GMT  
 Creating Objects and Performance

Quote:

> I was reading not to long ago a posting and the person that wrote it
> mentioned that there was a "good" way and a "bad" way to instatiate an
> object. One way caused the compiler to check each time the object was
> referenced to see if it had been set yet.  The other the compiler
> knew.  I think as an example.

> Right way

> Dim x as new obj.class

> for i = 1 to ubound(t)
>   x.Days = x.Days + 1     'Compiler knows it has reference, no extra
> work
> next

I'm afraid not.  X isn't actually instantiated untl the first time
it is used, so the compiler's still checking every time you use it.

Quote:
> Wrong way

> Dim x as obj.Class
> Set x = new obj.class

> for i = 1 to ubound(t)
>   x.Days = x.Days + 1     'Compiler has to check reference has been
> set.
> next

> Can someone confirm/correct that?

I have no idea why "As New" should be slower, except for the usual
Micro$haft laziness/incompetence.  I mean really, why should trapping
a nil-pointer dereference and raising an error be inherently faster
than trapping the same nil-pointer dereference, creating an instance,
and continuing as if nothing had happened?  Of course, "As New" also
has the "undead object" problem, meaning you can't even use ObjPtr(X)
without possibly instantiating it.  (X Is Nothing) can never be True,
and that could be a serious problem in error handlers, for example --
if an object Is Nothing, then I don't have to worry about shutting it
down properly, do I?  =)

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!



Tue, 26 Oct 2004 02:43:42 GMT  
 Creating Objects and Performance
Found on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnco...
ml/complus_implementing.asp

Do Not Declare Variables "As New."

When you declare a variable of an object type, you can use the As New.
keyword. This saves the effort of writing the line of code that actually
creates the object. However, this will cause every reference to the object
to be slower, and may surprise you with an unexpected object lifetime.
Furthermore, when used in combination with private classes it may bring
unexpected thread behavior.

More Information

When you declare a variable with the As New. keyword, you are telling Visual
Basic to create an object instance for you whenever you need one. This will
cause Visual Basic to compile your source with extra checks to see if the
object is set to Nothing. If the object has not been destroyed, Visual Basic
will create a new object every time the variable is used.

Some results in object lifetime may be surprising as well.

Dim o As New Project1.CSample

o.Foo

Set o = Nothing

MsgBox o Is Nothing 'False! o will never be visibly Nothing

This kind of behavior will make your code harder to maintain and may cause
errors that are difficult to spot. Using the As New keyword also has
repercussions on how the object is created (read the following item for more
information).

Do Not Create Objects in the Same Project with "New"

When using the New keyword to create an object in the same project, you are
bypassing COM+ object creation mechanisms, and therefore your objects will
not have the expected behavior under transactions, when working with
security or regarding threading.

In COM+, both the New keyword and the CreateObject function will flow the
context (transaction, security, and so on) into the child object if the
object being created is in another project. If both the creating (parent)
class and the child class are in the same Visual Basic project, you will
need to use CreateObject.

J-F


Quote:
> I was reading not to long ago a posting and the person that wrote it
> mentioned that there was a "good" way and a "bad" way to instatiate an
> object. One way caused the compiler to check each time the object was
> referenced to see if it had been set yet.  The other the compiler
> knew.  I think as an example.

> Right way

> Dim x as new obj.class

> for i = 1 to ubound(t)
>   x.Days = x.Days + 1     'Compiler knows it has reference, no extra
> work
> next

> Wrong way

> Dim x as obj.Class
> Set x = new obj.class

> for i = 1 to ubound(t)
>   x.Days = x.Days + 1     'Compiler has to check reference has been
> set.
> next

> Can someone confirm/correct that?

> Thanks
> Jeff



Tue, 26 Oct 2004 22:53:42 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Performance problems when reading schema data from field objects

2. Performance Q: DLookup versus creating a Recordset

3. Performance of the Word VBA Object Model

4. Object Performance

5. performance of FileSystem-object

6. Implement Performance Object in VB

7. Passing Arrays to COM Object Slows Performance

8. Performance of ASP pages calling COM object methods

9. Objects, arrays and performance

10. COM Object performance question

11. Performance of ASP pages calling COM object methods

12. Objects, TreeView and Performance

 

 
Powered by phpBB® Forum Software