Time to Load App

[Gloopy]

Hi,
I have finished a project in VB.NET which is working well. My deployment issues (see separate post) have also been resolved following advise from this site and hence it is ready to go live. I have one final nagging issue though. The app takes about 20 seconds to load which, from a users perspective, is a little disconcerting as it looks like nothing is happening.

I am very new to coding (approx. 6-9 months as a hobby) and cannot work out how to use the VS debugger/tools to determine what is causing the delay when loading. The app is less than 1MB in size and so size doesn't seem likely to be the issue. Can anyone advise on how I should tackle the problem or point me to a resource which might help.

Many thanks and all suggestions are much appreciated.

If you need to see some code for any reason just ask.

Steve

[jmcilhinney]

Does the app do anything in the Startup event handler of the application or the Load event handler of the startup form?

[Nirwanda]

Yeah that shouldn't happen, especially not for an application of that size.

Does this "loading time" differ when you run the application from the VS debugger versus the .exe?
What is your application doing when it starts up?

There is stuff you can do to mask this issue of "it looks like nothing is happening", but your first prio should be to eliminate the cause instead, because again it shouldn't happen.

[i00]

App size is irrelevant, the application may just list data from a stored proc... if that takes 20 seconds to run the application will take ages to load (if done on the load event and not threaded etc)...

We really need to see what is happening in the .Load event Main Subs (if applicable) etc...

Kris

[topshot]

Not very elegant, but to determine what was running slowly on an app I wasn't real familiar with I just used a stopwatch to find which routines were using the greatest time and then drilled down from there. In the form Load event...

        Dim sw As New Stopwatch
        sw.Start()
        Dim swStr As String = "" 'this may be faster as StringBuilder???

        swStr = swStr & sw.ElapsedMilliseconds.ToString & " refresh DGV" & ControlChars.CrLf
        Me.OrderdtlBindingSource.DataSource = gTBLorderdtl
        OrderdtlDataGridView.Refresh()

        swStr = swStr & sw.ElapsedMilliseconds.ToString & " populate data" & ControlChars.CrLf
        PopulateData()
        
        swStr = swStr & sw.ElapsedMilliseconds.ToString & " update goals" & ControlChars.CrLf
        UpdateGoals()

        swStr = swStr & sw.ElapsedMilliseconds.ToString & " savechanges" & ControlChars.CrLf
        savechanges()
        
        swStr = swStr & sw.ElapsedMilliseconds.ToString & " getgoals" & ControlChars.CrLf
        getGoals()
        
        swStr = swStr & sw.ElapsedMilliseconds.ToString & " done" & ControlChars.CrLf
        MessageBox.Show(swStr)

Once I found the biggest hitters, I'd do the same in those routines. Run a few times to allow any startup overhead to even out though that didn't seem to matter. I was able to eliminate a call that wasn't needed and refactor a couple others to greatly improve the load speed once I knew where to focus.

[i00]

You said you were using 2015... If you place a break point on getGoals() - for example then step over it it should tell you the time between the code breaks... easier than placing stop watches everywhere!



Kris

[Gloopy]

Many thanks all. I like the idea of the stopwatch and the break points. I am not sure what you mean though by getgoals()?
This is not something I am familiar with. Apart from inserting the text shown, what else might I need to do to make this work?

[passel]

getGoals was one of the methods called in your load even that you posted.

All i00 was saying is that with VS2015 (at least for the VB language) when you step over method calls with the debugger, it will automatically tell you how long the method took to execute.

If you were trying to find out which call in your Form's load event was slow, you could have just stepped through the code in the debugger (not stepping into the method) and saw which were slow without having to add a stopwatch and gather the statistics yourself.

Since trying to identify methods that take a lot of time is such a common need, they built it in to the IDE.

[i00]

getGoals was one of the methods called in your load even that you posted.

All i00 was saying is that with VS2015 (at least for the VB language) when you step over method calls with the debugger, it will automatically tell you how long the method took to execute.

If you were trying to find out which call in your Form's load event was slow, you could have just stepped through the code in the debugger (not stepping into the method) and saw which were slow without having to add a stopwatch and gather the statistics yourself.

Since trying to identify methods that take a lot of time is such a common need, they built it in to the IDE.

I just re-read that post after Gloopy and yourself re-posted... that was actually topshot's reply .. oops

Kris

[passel]

My apologies as well.

[i00]

.. Yea it was worded like an OP reply

[Gloopy]

Thanks all. The break points helped greatly. I had a rogue call to Excel which was slowing things down. Once this was moved, the app opens in a flash.

Thanks to all for the time taken to reply to this thread

Steve