Why is Matlab R2016a lagging so bad right after I open it?

I cannot use Matlab. Immediately when I open it, it begins to lag very badly. Also, there are only two files in my folder. Do I need to reinstall Matlab? My activity monitors shows that I have plenty of memory, so that's not the problem.

There is a yellow bar under my files with the word "processing" I think this may be the problem because when I cancel it, I can actually use Matlab. However, I don't know what "processing" means.

[Walter Roberson]

Which operating system are you using?

Which directory are you cd'd to when you start, and is it a network drive?

[Real Name]

@Walter, I am using Mac OS X. I am in a Matlab directory when I start. It's not a network drive. There is, however, a yellow tab that loads with "processing" which I think contributes to the slowness, due to the fact that when I cancel it, I can actually use the software.

Answer 1

[Walter Roberson]

Go into your Preferences in MATLAB and turn off Source Code Control.

This is an issue that affects only OS-X. It was supposedly fixed in R2015b (if I recall correctly) but some people have seen it in R2016a still.

[Real Name]

That worked thanks! But what is source control and will I need to use it ever?

[Walter Roberson]

You might want to use it at some point.

Source Code Control is for working with projects in which you might have multiple authors, or you might be using a deliberate policy of creating "versions" of programs.

For example if you were working on a long term project, it would be common to identify a bug, figure out what needs to be changed, tell the system you want to be able to edit the appropriate files, edit them, test that the fix worked and nothing broke with the change, and then "check in" those files again, together with a description of what was changed. In this way, particular versions of files are known to have particular behavior together, so you can easily replicate the particular combination of sources that were used. And you can go back and read previous versions of the files. Which could be pretty important if you later discovered that something broke after all.

For example, I would create combinations of source files that I thought worked (or which I thought I knew the limitations of), and I would "release" that combination to my supervisor. And while my supervisor explored the program, I would continue editing. My supervisor would come back and say "This doesn't work" or "Can we change this?". I would then be able to grab copies of the source as they were at the time I released them and replicate the problem, even though the sources I might be in the middle of editing for further development might be in a completely inconsistent state (some edits take months!). I could make small changes to that version, and "check in" those changes -- all while having my own versions due to whatever I was working on otherwise. Eventually when my other changes were ready, I could "merge" the various branches together producing a version with all of the changes.

You can, of course, always do the same thing by setting up directories and copying files around and trying to remember what each directory is for, but using a source code control program is really good discipline, encouraging cycles of more limited changes that you can test to work, where-as otherwise a directory tends to become a "kitchen sink" of changes that can be difficult to make sense out of. And if you have a deadline breathing down on you, then if you have been using source-code control you can always pull out a known-state version instead of plunging like mad trying to unclog that kitchen sink...