Hi, im currently writing a script in R2016a. It is 18k lines long right now, and it's done for about 25%. However, the programming gets really slow right now (it did since about 12-15k lines). The running of the script goes just fine, but when I try to edit it it severely lags: whatever I type into the code takes several seconds to actually appear. Does anyone else have similar experience with this issue and an idea on how to fix it? Thanks a lot!
MATLAB: Programming long script gets extremely slow
laglong code
Related Solutions
I never write scripts, because the variables declared in one script interfere with other scripts. Any possibility to influence parts of the code, which are far awy, is a source of bugs - see https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_science).
But the question remains, when to separate a part of a function to create a new function. This can be desided by the code complexity, but it is a question of taste, how you measure it and where the limit is. But as soon as a piece of code is a compact unit, which can be reused from other functions also, it is worth to move it to an own function. Then it be be tested exhaustively by a unit-test. If it is a bottleneck for any code, it can be optimized or mex-ed, and then all codes using this subfunction wil profit from the speed.
There is a certain overhead in calling an M- or built-in function. The latter is faster, e.g. calling mean(X) is slower than sum(X) / numel(X). But this overhead is small.
Sometimes the error checks in functions take more time than the actual computations (see polyfit). But this is a different problem.
While the runtime of inlined code can save milliseconds of runtime compared to functions, the time for programming and debugging can profit massively from this. If you have 4 almost identical parts, it will be a mess to apply a modification of the code compared to having 1 external function with a parameter for the differences. Therefore copy&paste programming is considered as anti-pattern. Maintaining or expanding such code is too prone to typos.
Caring too much about the runtime during the programming is often a premature optimization: The goal is to solve the problem. Then concentrating on the runtime at the beginning can lead to unreadable code which cannot be adjusted or expanded anymore. It is smarter to create a stable and clean code at first and find the bottlenecks for the runtime later. Then you can be sure not to "optimize" any code, which takes 1% of the total runtime only, such that a 100% speedup of this part reduces the total runtime by 0.5% only.
I've seen the advice, that subfunctions must be created, when the main function exceeds 1000 lines of code. Others use the a limit of the "Cyclomatic complexity", e.g. McCabe complexity > 10 to determine the need to move code to subfunctions to allow a complete testing. Another idea is: "If you cannot describe the job of a function in one sentence anymore, split it into subfunctions."
You see: runtime does not appear in the criteria, but the reduction of complexity rules to avoid bugs and improve the maintainability.
You totally misunderstand the issue if you think that eval, evalin or assignin are faulty.
There is nothing wrong with eval, evalin, or assignin, in the sense that they work exactly as documented and do exactly what they are supposed to do. Sometimes these functions are useful. But...
The problem is that what they do lets many beginners use them totally inappropriately, to solve tasks that would be much better solved using simpler, faster, neater, more efficient, easier to debug and much more robust methods (usually indexing is the simpler solution). Simply put, those beginners design their code in such a way that they force themselves to write bad code: slow, buggy, hard to debug, insecure, complex, ugly code. By deciding to write such bad code they remove all of the inbuilt code checking and code helper tools. They also remove any ability for the JIT compiler to speed up their code. They remove the ability to search for and locate variables. The list goes on. Even if all other things were equal, any one of these disadvantages would be reason enough to avoid dynamic variable names.
Or, to put it another way, the problem is not using eval in particular, the main problem is dynamically accessing variable names. It just happens that magically defining or accessing variable names is most commonly achieved using eval and assignin, but the problem actually occurs regardless of what tool or method is used to access them: it also applies to load, for example, when load is called without an output variable.
You need to stop asking "what is the problem with eval?", and start asking yourself "why is it so inefficient to dynamically access variable names?". To help understand some of the issues that is causes, read this thread:
You are not the first beginner to ask this question. Some of them get really confused, because they think that there is a problem with eval. For example, read this discussion, including all of the answers and comments:
"The experienced contributors to the forum always emphasize avoiding usage of assignin and eval functions due to many reasons."
You will notice that the title of my tutorial is actually "TUTORIAL: Why Variables Should Not Be Named Dynamically (eval)". All of the discussions and links within that tutorial are focused on one topic: dynamically accessing variable names. You need to start reading about this topic if you really want to understand it.
Best Answer