Bug 829 - Restoring previously opened document tabs is slow
Summary: Restoring previously opened document tabs is slow
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: 2.8.5
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Alan McGovern
Depends on:
Reported: 2011-09-15 07:15 UTC by Chris Hardy [MSFT]
Modified: 2012-01-31 10:40 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Chris Hardy [MSFT] 2011-09-15 07:15:29 UTC
When opening a project all the files that were last opened in that project are restored.  However the behavior has changed with the newest MD.  Each file opens individually where it used to have them all open at once.  It's pretty annoying waiting for all the file to open themselves before you can do anything.
Comment 2 Jeffrey Stedfast 2011-11-15 12:06:48 UTC
We probably shouldn't re-open all the previously opened files. That's the simple fix, and probably the right fix in the long run.
Comment 3 Mikayla Hutchinson [MSFT] 2012-01-03 13:48:46 UTC
I think we need to make the file loads lazier. They're doing a lot of work they don't need to do until the tab is actually displayed, e.g. determining the display binding to use, parsing the document, etc.
Comment 4 Jeffrey Stedfast 2012-01-04 16:18:22 UTC
I think I may have been smoking crack in comment #2. Just an FYI.
Comment 5 Jeffrey Stedfast 2012-01-10 17:56:24 UTC
I've done a fair bit of work on this recently, but there's still a lot to do :-\

iirc, 25% of the time loading now is in the VersionControl logic that adds the Diff/Blame/Merge/etc buttons at the bottom of each document.

It seems like it is generating diffs/etc when it creates each of those alt views which it should be made not to do until the user actually clocks those tab buttons. Not just for performance, but also for memory usage reasons.

Another good chunk of the time spent (12%?) is in Stetic deciding whether or not the class corresponds to one of the widgets defined in the stetic files.
Comment 6 Jeffrey Stedfast 2012-01-10 17:56:59 UTC
Ccing Alan so maybe he can look into lazy-loading the VersionControl UI.
Comment 7 Alan McGovern 2012-01-10 21:06:53 UTC
I was looking at lazifying the version control tabs earlier actually. It should be possible to delay the addition of the version control subviews until the tab is the active and selected one. I had a patch which did it but it caused some rendering issues so I need to look into that.
Comment 8 Alan McGovern 2012-01-31 10:40:32 UTC
This has all been resolved now. We're *very* lazy when it comes to instantiating the UI components for the tabs and it has significantly improved the speed at which tabs open.