locked
Why is it taking 10 seconds to close a screen (Connect Bug 730385)?

    Question

  • This problem just started happening on one particular List Detail screen in my app.  After clicking the "x" to close the screen it just sits there for about 10 seconds before it closes.

    It happens every time I close this screen, even when I have not done any data entry / editing within the screen.  It is not waiting to save anything to the database.

    To reproduce, all I do is:

    1. F5 to run the app, and open the screen.  The screen runs its queries and populates all the controls with data.

    2. Click to close the screen. Nothing happens visually for about 10-11 seconds.  Then the screen closes

    I don't have any logic coded in the <screen>_Closing method.

    I have tried rebuilding the solution and restarting VS11.  I turned on client side tracing and compared this slow screen to a similar good screen and can't tell much difference.  Below is the trace for this slow screen:

    [Microsoft.LightSwitch.UserCode][Application:Information][Close:Execute] Invoking user method: Companies_Manage.Close_Execute

    [Microsoft.LightSwitch.UserCode][Application:Verbose][Close:Execute] A user implemented method does not exist.

    [Microsoft.LightSwitch.UserCode][Application:Information][LightSwitchApplication:Companies_Manage:Close] Invoking user method: Companies_Manage.Companies_Manage_Closing

    [Microsoft.LightSwitch.UserCode][Application:Verbose][LightSwitchApplication:Companies_Manage:Close] A user implemented method does not exist.

    [Microsoft.LightSwitch.UserCode][Application:Information][LightSwitchApplication:Companies_Manage:Close] Execution completed.

    'chrome.exe' (Silverlight): Loaded 'Microsoft.GeneratedCode'

    [Microsoft.LightSwitch.Screens][Application:Information][LightSwitchApplication:Companies_Manage:Close] Screen closed.

    [Microsoft.LightSwitch.UserCode][Application:Information][Close:Execute] Execution completed. 'chrome.exe' (Silverlight): Loaded 'Microsoft.GeneratedCode'

    [Microsoft.LightSwitch.UserCode][Application:Information][Close_CanExecute:CanExecute] Invoking user method: Companies_Manage.Close

    [Microsoft.LightSwitch.UserCode][Application:Verbose][Close_CanExecute:CanExecute] A user implemented method does not exist.

    [Microsoft.LightSwitch.UserCode][Application:Information][Close_CanExecute:CanExecute] Execution completed.

    Before this started happening I was doing some coding in the Screen Designer (design time, and run time), adding a few controls, F5, adding some more controls, F5, etc.

    Other screens in my app are closing just fine.

    Has anyone else seen this slowness in any of your screens when closing them?


    Ed Taylor


    • Edited by Ed Taylor Sunday, March 11, 2012 4:08 AM
    Friday, March 09, 2012 7:15 AM

Answers

  • I was able to improve the screen closing performance from the painfully slow 10 seconds to a brisk 1.5 seconds!  I'm happy now :)

    I did not need to compromise my original screen design.  I am nesting controls up to 10 levels deep.  And my screen design utilizes Tab Layouts within Tab Layouts... nice!

    How?

    I went back through my screen design and discovered 5 places where I had used Row Layout groups that were redundant (i.e. there was only 1 child row inside the group).  I re-designed the screen to remove those 5 Row Layouts, and that alone significantly improved the performance.

    See old vs. new below:

    Take away lesson I have learned is to be careful when adding Group controls to the screen layout in LS V2, and try not to nest too deep. Don't add a Row Layout or other group layout "just in case its needed later" if you don't really need it.

    Maybe LS Team can figure out why this happens in LS V2 but didn't seem to bother LS V1 (SL5 vs. SL4?), at least in my case.  In any case I know how to get around the issue now.  Hope this post helps someone else save some time.


    Ed Taylor



    • Marked as answer by Ed Taylor Sunday, March 11, 2012 3:40 AM
    • Edited by Ed Taylor Sunday, March 11, 2012 3:44 AM
    Sunday, March 11, 2012 3:38 AM

All replies

  • Hi Ed,

    Performance is something that we are focusing on in LS V2. I have also noticed operations that seem to be slow. Any further details that you could provide would be much appreciated. i.e.What kind of app (web or desktop), what is your data source, anything beyond basic screen behavior that you are doing with this screen? If you can provide a consistant reproduction of the problem, please post on Connect.

    Thanks,


    Steve Hoag Microsoft aka the Lights Witch (IEnumerable of Newt)

    Friday, March 09, 2012 7:47 AM
  • Thanks for the reply Steve.

    Its a desktop app, but slowness happens even when running it as a web app.  Intrinsic database only.  Win7 64bit.

    It actually *is* happening with some of my other screens too... screens that I have not touched since converting to VS11beta. 

    I ran the same screens under VS2010 and compared screen opening and screen closing times.  Both are slower under VS11beta, but screen closing is really slow for these more complex screens.

    Seems to be a function of the complexity of the screen design (lots of nested control groups), but I'm just guessing.

    I use FindControl a lot to enable/disable and hide/show.  I also have a lot of _CanExecute and _Execute code.  But I commented all that out to see if it improved the performance.  Nope.

    I will do some more analysis later when I have more time and post if I find anything.

    Thanks,


    Ed Taylor

    Friday, March 09, 2012 2:25 PM
  • I installed Fiddler and confirmed that after I click to close the screen, the client is not sending any traffic to the server.

    So whatever is delaying the screen closing for 10 seconds after I click to close is happening all on the client side.

    The client side trace I posted earlier is not helping much.

    I added a Debug statement in the <screen>_Closing method to log the time that method is entered.

            partial void Companies_Manage_Closing(ref bool cancel)
            {
                Debug.WriteLine(DateTime.Now.ToLongTimeString() + " <screen>_Closing executed");
            }

    When I ran my next test I observed that almost immediately after I clicked the "x" to close the screen this _Closing method fired and I saw the Debug line in the Output window:

    1:32:30 AM <screen>_Closing executed                                     <====  displayed immediately after clicking to close screen

    Nothing else was logged in the Output window for the next 10 seconds even with client side verbose tracing on.  During this time the screen stays open.

    Wondering if Microsoft team or others can tell me of any other approaches for tracing what is happening on the client?  I tried stepping through the code in the debugger after breaking inside the _Closing method, but there is no more of my code to trace at that point.

    Thanks,


    Ed Taylor

    Saturday, March 10, 2012 8:19 AM
  • Ok, through lots of trial and error I think I found the issue.  It appears to be related to how deep the screen layout groups/controls are nested. Go too deep and the performance problem occurs.   

    When I rearranged one particular Tab Group to reduce its nesting from 7 levels to 3 levels deep, I improved the Screen Close performance from 10 (almost 11) seconds to under 3 seconds

    See below screen shots showing the "before" and "after" screen design:


    The group that I rearranged to reduce its nesting is shown below.  It has 5 more levels of nesting within it:

    Of course this rearrangement totally destroyed my screen design so I'm hoping the performance work that Steve Hoag mentioned Microsoft is currently doing with LS V2 will allow me to continue designing screens that nest up to 12 or more levels deep.  I tried this same "deep nesting" screen layout in LS V1 and it exhibits no performance issue... screen closing is nearly instantaneous.

    Curious if anyone else has screens with this level of nesting, and if you are seeing similar slowdowns in VS11 beta when closing the screen?


    Ed Taylor



    • Edited by Ed Taylor Saturday, March 10, 2012 6:52 PM
    Saturday, March 10, 2012 6:31 PM
  • This feels like a Silverlight issue rather than strictly a LightSwitch issue.

    Nesting a Tabs Layout inside another Tabs Layout may be the issue.

    Perhaps see if performance is changed by replacing the Tabs Layouts ?


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com

    Saturday, March 10, 2012 7:23 PM
  • This feels like a Silverlight issue rather than strictly a LightSwitch issue.

    Nesting a Tabs Layout inside another Tabs Layout may be the issue.

    Perhaps see if performance is changed by replacing the Tabs Layouts ?


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com


    and that lead to LightSwitch can not handle complex issue

    Saturday, March 10, 2012 7:56 PM
  • and that lead to LightSwitch can not handle complex issue

    1) I may not be correct :)

    2) You can use Silverlight Custom Control for greater control of the UI: Help Desk: An Advanced Visual Studio LightSwitch Application

    3) There is no RIA technology can has better performance than Silverlight. Not Java or Flash.


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com

    Saturday, March 10, 2012 8:25 PM
  • Thanks for the suggestion Michael.  I replaced the inner Tab with a Row Control and it did shave off 2 seconds... so the user waits 8 seconds instead of 10 for the screen to close after they click it :)

    With respect to designing screens with Tab controls within Tab controls, even Microsoft uses that design layout in their Course Manager sample application, so I would think it is supported. 

    [Edited after posting...  My statement above is not really accurate.  The above screen is showing a Tab Control within a Screen, not within another Tab Control.  Hopefully MS will tell us this combination is supported.]

    Also, please note... as I mentioned previously, LS V1 has absolutely no issue with this exact same screen layout.  No performance issue at all.  Something has changed in LS V2beta.


    Ed Taylor



    • Edited by Ed Taylor Saturday, March 10, 2012 10:15 PM
    Saturday, March 10, 2012 9:27 PM
  • and that lead to LightSwitch can not handle complex issue

    1) I may not be correct :)

    2) You can use Silverlight Custom Control for greater control of the UI: Help Desk: An Advanced Visual Studio LightSwitch Application

    3) There is no RIA technology can has better performance than Silverlight. Not Java or Flash.


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com

    Well...

    I appreciate your work ,but  what i know

    the purpose of LS is to let you focus on your User Business Requirements rather than waste your time to write code for inserting, updating, deleting and validation and so on

    now LS solve this problem but put me in another big one ,that i have to create Silverlight Custom Control , and its seem we will need more than one custom control.

    i know you can sale me some of them ,but trust me i prefer to stay with tradition WinForm using VS2008 rather than facing risks of LS limitation.

    in my opinion LS is good for creating Mini LOB app.

    by the way if you have time take look at 

    http://social.msdn.microsoft.com/Forums/en-US/lightswitch/thread/bb45818b-fa26-44e9-8028-d79aba137426

    Saturday, March 10, 2012 9:28 PM
  • in my opinion LS is good for creating Mini LOB app.

    by the way if you have time take look at 

    http://social.msdn.microsoft.com/Forums/en-US/lightswitch/thread/bb45818b-fa26-44e9-8028-d79aba137426

    If I had a large amount of nested controls on on Windows Forms app I would still take a performance hit.

    I don't feel that an isolated performance issue supports a statement that LightSwitch cannot handle large LOB apps.

    Check out the LightSwitch Star submissions on Code Project for examples of large LightSwitch LOB apps :)


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com


    Saturday, March 10, 2012 9:56 PM
  • The Microsoft example does not have a large amount of nesting so if they are taking a performance hit it may still be small overall.

    LightSwitch now uses Silverlight 5 so that could still point to Silverlight being the issue.

    Again, I am just wondering out loud since it is a weekend and the LightSwitch team may not respond until Monday :)


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com


    Saturday, March 10, 2012 10:00 PM
  • I am optimistic that as we help Microsoft shakedown this LS V2 *beta* these kind of performance issues will improve.

    Generally I agree with the saying "Make it work, Make it right, then Make it fast".

    Again, LS V1 handles this level of screen design (in my particular case at least), so hopefully LS V2 can figure out how to make it fast also. 


    Ed Taylor


    • Edited by Ed Taylor Saturday, March 10, 2012 10:34 PM
    Saturday, March 10, 2012 10:05 PM
  • I was able to improve the screen closing performance from the painfully slow 10 seconds to a brisk 1.5 seconds!  I'm happy now :)

    I did not need to compromise my original screen design.  I am nesting controls up to 10 levels deep.  And my screen design utilizes Tab Layouts within Tab Layouts... nice!

    How?

    I went back through my screen design and discovered 5 places where I had used Row Layout groups that were redundant (i.e. there was only 1 child row inside the group).  I re-designed the screen to remove those 5 Row Layouts, and that alone significantly improved the performance.

    See old vs. new below:

    Take away lesson I have learned is to be careful when adding Group controls to the screen layout in LS V2, and try not to nest too deep. Don't add a Row Layout or other group layout "just in case its needed later" if you don't really need it.

    Maybe LS Team can figure out why this happens in LS V2 but didn't seem to bother LS V1 (SL5 vs. SL4?), at least in my case.  In any case I know how to get around the issue now.  Hope this post helps someone else save some time.


    Ed Taylor



    • Marked as answer by Ed Taylor Sunday, March 11, 2012 3:40 AM
    • Edited by Ed Taylor Sunday, March 11, 2012 3:44 AM
    Sunday, March 11, 2012 3:38 AM
  • Take away lesson I have learned is to be careful when adding Group controls to the screen layout in LS V2.  Don't add a Row Layout "just in case its needed later to add something underneath" if you don't really need it.

    Maybe LS Team can figure out why this happens in LS V2 but didn't seem to bother LS V1 (SL5 vs. SL4?), at least in my case.  At least now I know how to get around the issue.  Hope this post helps someone else save some time.


    Ed Taylor

    Thats great news. Perhaps you can still file a Connect bug at:

    https://connect.microsoft.com/VisualStudio/feedback/CreateFeedbackForm.aspx?FeedbackFormConfigurationID=4861&FeedbackType=1

    It appears you have isolated the issue so they can address it.


    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com

    Sunday, March 11, 2012 3:42 AM
  • Done.   Connect Bug 730385


    Ed Taylor

    Sunday, March 11, 2012 4:05 AM
  • Done.   Connect Bug 730385


    Ed Taylor


    Good. I clicked on the green arrow to give it an extra vote.

    Make Them Ask: That's a LightSwitch App?

    http://LightSwitchHelpWebsite.com

    Sunday, March 11, 2012 5:54 AM
  • I gave your connect bug a vote because the time for closing a tab with more complex content (but nothing really special in my opinion) has pretty much increased. In my case from immediately in present version to 5 sec in Beta. Thanks for pointing to that problem.

    Uwe

    Sunday, March 11, 2012 7:53 AM