Design Time or Run Time?

[Lunatic3]

I have had this question always in my mind. Imagine I have at least 5 dataadapters to be added to my form and in the life cycle of the form I need to refere to them from time to time. So i have three choices:
1-Add them in desgin time then when the form is intialized the connection, dataadapters and dataset are intialized and kept active until I close the form and all disposed.
2-Add them at run time and do not dispose them then it has the same impact as the previous one.
3-Add them at run time when needed and then dispose them when finished with them, and repeat this each time needed.

Which one of the above solutions you suggest? and why? I just bring dataadapters as example, it can be any object.

[VBCrazyCoder]

I personally like to keep a tight reign on my objects, and only instantiate them when I need to use them, and dispose of them immediately when I am done with them.

However, sometimes this means using late binding vs. early binding - if using polymorphism such as:

Dim myObj As Object

Above I decare myObj to be of type object, then at run time I instantiate the object (New) to the type of Object that I wanted (in my case a particular form). This saves me from declaring each form at design time, and then not even using most of them - or at the very least it saves me from typing the declaration of:

Dim myobj1 as Form1

Late binding incurrs a performance hit because the compiler can't perform it's optimizations, type checking, and member lookup. So more work has to be done at runtime. However, I don't think the performance hit is significant (although I have not actually tested it, but doesn't seem to slow it down).

[TheExtreme]

In most cases with VB.NET there will be little to no difference thanks to managed code and garbage collection. This of course is dependant on the object and its dependencies. Application or Form load time may need to be considered. Should you decided to create and destroy your objects at run time. Remember that .NET uses garbage collection and may not truly destroy the object. You can use "gc.Collect" to force garbage collection though is not recommended unless you have a long lived application that goes idle for sometime.

[Edneeis]

I would say late binding should be avoided at most costs. Just running a simple test:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim tStart As DateTime = DateTime.Now
        Dim obj As Object
        obj = New Form4()
        obj.Show()
        Dim elapsed1 As Single = Now.Subtract(tStart).TotalMilliseconds
        tStart = DateTime.Now
        Dim frm As Form4
        frm = New Form4()
        frm.Show()
        Dim elapsed2 As Single = Now.Subtract(tStart).TotalMilliseconds
 
        MsgBox(String.Format("Object: {0}{1}Form4: {2}", elapsed1, ControlChars.NewLine, elapsed2))
 
    End Sub

Shows that late binding is upto 6 times slower and this is just for simple objects, not to mention the fact that this takes away some of the error checking done during compiling. If its relevant to the project I say go for it, but if you know the object type ahead of time then don't. You could say that today's machines are fast enough and even in this test the difference is in milliseconds, but why slow things done without need.

[Edneeis]

Actually my little test revealed more than I thought. Try changing it to this:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim tStart As DateTime = DateTime.Now
        Dim obj As Object
        obj = New Form4()
        obj.Show()
        obj.close()
        Dim elapsed1 As Single = Now.Subtract(tStart).TotalMilliseconds
        tStart = DateTime.Now
        Dim frm As Form4
        frm = New Form4()
        frm.Show()
        frm.Close()
        Dim elapsed2 As Single = Now.Subtract(tStart).TotalMilliseconds
 
        MsgBox(String.Format("Object: {0}{1}Form4: {2}", elapsed1, ControlChars.NewLine, elapsed2))
    End Sub

The first time the code runs there is a large difference but if you continuely run it then there is no difference after that, unless you restart the app. Which although it counters some of what I said, it also shows how cool the MSIL compiler bit is, and the effects of the garbage collector.

[Lunatic3]

Thanks for your input. So you mean that If i know the object type I try to add them in design time?

You can use "gc.Collect" to force garbage collection though is not recommended unless you have a long lived application that goes idle for sometime.

In fact this is what i am facing. In one of my projects I have a Crystal Report page that the user may just be using that form for more than 1 hour or so trying to print out the pages that is sometimes more than 1500 pages(The temp file of this report may be as large as 700 mb). So when this form is going to close and return to the main page it takes a little more time than if you quickly close it and not let it idle for long time. So do you recommend that I try to invoke GC on another thread while the user is busy with printing? and if yes, then at what interals? how can I guess when is the right time?

[PT Exorcist]

i dont know if i am 100% right but using GC.Collect wont clean up any resources..the only thing it will do is set the objects as ready for finalization so next time the garbage collector executes it will delete the object

http://www.gotdotnet.com/team/librar...#_Toc522530574

[TheExtreme]

Lunatic3,

based on everything I have seen gc.colllect tells the GC that now is the best time to clean and reallocate memeory. Which is why I only reccommed this procedure on apps that are idle for some time.

The garbage collector's optimizing engine determines the best time to perform a collection

From my experience "gc.collect" forces this to happen.