large files, very slow editor, no fix?

Changes to the editor in R2011 have dramatically slowed down the editor when working with large m-files (e.g. 1000's of lines). I have been in correspondence with support staff, who tell me to disable cell mode and break up the file into smaller files.

Disabling cell mode does help somewhat, but there is still a lot of latency while typing. It can be several seconds to see what was typed. Even scrolling is choppy.

So the next step is break up the large file. But here's the problem. Most of the functions within the file are nested functions, which share the scope of the parent functions. How do I move the nested functions to separate files and maintain the behavior of nested functions?

Answer 1

[Michael Katz]

Try also increasing the size of the Java heap. File -> Preferences -> General -> Java Heap Memory. It may not help, depending on where the time is being spent, but it's worth a shot.

[Scott]

That fixed it completely! I octupled the Java heap and the editor is snappy and vivacious again.

Thank you user community!

[Scott]

Well, maybe that isn't the only problem. At first, the editor is fast, but before long it slows way down again.

Answer 2

[Andrew Drake]

put "exit" on the first line

[Scott]

At first, I thought this was just a snarky response. But then I got to thinking it might have some impact on the MTree functionality, so I tried it.

Indeed, it effectively turned off MTree and let me edit the file without any slowdowns. Of course, it also turns off error checking and disables the "show functions" popup menu, but keeps code folding functional.

It is a lot more convenient than the "official" Matlab workaround of issuing "com.mathworks.services.Prefs.setBooleanPref('CodeParserServiceOn',false)" and restarting Matlab. At least I don't have to wait through a restart. I just have to remember to remove the "exit" before saving changes.

An alternative to "exit" on the first line would be anything that produces an error, such as a simple "x".

Answer 3

[Oleg Komarov]

By moving the nested functions to separate files you will:

1. Lose the ability to see the parent's function workspace
2. Other functions will see them and you may get into conflicts

To solve 2. you can make the ex-nested functions private.

To solve 1. you have two options:

• Add inputs to your ex-nested functions (no big news here).
• [STRONGLY UNRECOMMENDED] Hardcode assignin calls.

[Scott]

Moving the fifty or so nested functions to external files is already a real pain, and adding an input list of dozens of variable is even worse. If this is the course of action I have to take, then Matlab is starting to look like a very undesirable programming environment. Perhaps my best option is to revert to R2009, before the editor was broken, and keep the nested functions.

I hadn't thought of the assignin option. Why do you say strongly unrecommended?

[Oleg Komarov]

Because you have to hardcode the names and if you change the name inside your main function (very likely to happen, I change names continuosly) then good luck extending the change to the private functions.

Another solution is to use subfunctions, you won't have to manage 50 files and the scope is limited to the main function. Don't know though if cell mode will give you problems, but worth giving it a try. You could save all the relevant variables in a struct and pass a single variable to the subfunctions...but again it is a sort of hardcoding.

[Scott]

I suspect the problem would persist with subfunctions, too. My guess is that the slowdown comes from the new features in the editor, such as expanded use of syntax coloring, and the highlighting of all instances of the word adjacent to the cursor throughout the entire file. I don't see a way to turn that off.

I wish there were a command that would expand the scope of a function to include the scope of another function, like ExpandScope('parent_function').

[Michael Katz]

If the latency is related to the code structure, using subfunctions would help, as the editor needs more power to process deeper into nested code. Without seeing the code, it's hard to make a good judgement, but if the nesting is several levels deep, maybe it can be rewritten to use fewer levels. Also consider using a class object if that data has to be shared within that many function calls.

Answer 4

[Daniel Shub]

You could switch to an editor like emacs/vim.

You could move your nested functions to separate files. Then write another function that writes a new mfile that integrates your nested functions into the main function.

Divide your code up into smaller and reusable blocks. Use structures to efficiently pass the formerly nested functions arguments.

[Scott]

OK, I'm open to the idea of a new editor. Would it integrate well into Matlab? I'm using Win7 64bit.

Would it use color to differentiate the various parts of the syntax? Would it flag syntax errors and make suggestions for correction? Does it fold sections of code? Autosave? Does it permit stepping through the code in debug mode, with the value of variables popping up when hovering over them? Will it let me jump to the offending line of code after clicking on an error message?

If so, I'm very interested in looking into this!

[Daniel Shub]

I don't use emacs with MATLAB, but more details can be found at:

http://blogs.mathworks.com/desktop/2009/09/14/matlab-emacs-integration-is-back/

and

http://matlab-emacs.sourceforge.net/faq.shtml

for more details ...

Would it use color to differentiate the various parts of the syntax? Yes

Would it flag syntax errors and make suggestions for correction? To some degree. It integrates with mlint.

Does it fold sections of code? I believe there are emacs plugings for this.

Autosave? Yes

Does it permit stepping through the code in debug mode, with the value of variables popping up when hovering over them? I am not sure on this one, but it looks like it.

Will it let me jump to the offending line of code after clicking on an error message? Yes

Answer 5

[Andreas Goser]

I know of a couple of examples where disabling cell mode completley healed the issue. Actually, I know only of one counter-example and this was a user who had his large MATLAB Code on an external server (mapped drive). If this is the case for you, please try putting the file local.

[Scott]

All of my files are local. Cell mode is off. The problem most definitely persists! Text appears up to 5 seconds after I type it. The find function takes several seconds to find the next instance, even if it is on the next line! When I drag the scroll bar, it freezes periodically. I'm not using an underpowered machine. I have 6GB of memory and 200GB free disk space. The clincher is that the problem does not happen on this machine with R2009.

[Andreas Goser]

Well, it was worth a try...

[Scott]

I appreciate your giving my problem attention!

Answer 6

[per isakson]

An object oriented design with methods in a separate @-folder should solve the problem with the editor.

Rewriting object oriented code, which is implemented with nested functions, might not be as bad as it sounds. I've done it a few times (for other reasons) with pre-R2008a m-files. At most a couple of thousand lines. However, it is certainly not a quick-fix.