Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
Drexel University or The Math Forum.
|
|
|
|
Re: how to implement the "many tiny functions" paradigm?
Posted:
Jan 10, 2013 3:02 PM
|
|
"kj" <no.email@please.post> wrote in message
news:kcn2qd$ld5$2@reader1.panix.com...
> In <kclpkc$65b$1@newscl01ah.mathworks.com> "Bruno Luong"
> <b.luong@fogale.findmycountry> writes:
>
>>kj <no.email@please.post> wrote in message
>><kckj4h$m4s$1@reader1.panix.com>...
>>>
>>>
>>> One of the most often cited coding "best practices" is to avoid
>>> structuring the code as one "large" function (or a few large
>>> functions), and instead to break it up into many tiny functions.
>>> One rationale for this strategy is that tiny functions are much
>>> easier to test and debug.
>
>>I would be careful when applying blindly this "best practice". MATLAB have
>>huge running performance penalty due to function overhead (as opposed to
>>other programming language as C, fortran, ...)
>
>>You will slow down the code by putting simple (scalar) arithmetic
>>expressions in function. If the expression is vectorized and supposes to
>>operate on big array, then it's OK to put it in the functions.
>
>
> To be sure, the benefits of using many tiny functions over a few
> big ones need to be weighed against the performance costs of the
> additional function calls. This is always true.
>
> In practice, however, I've found it is possible to narrow down
> significantly the performance-critical parts of the code, outside
> of which, the added cost of the additional function costs becomes
> negligible. This usually creates a fairly large scope of applicability
> for the "tiny functions" strategy. (I.e., a 100-line function may
> be boiled down to ~10-20 2-3 line functions, and one 15-line
> performance-critical computational "core".
Depending on what you're doing, there are three possibilities that you may
want to explore.
If all these "tiny functions" are only used by your application, and your
tests will live in the same directory, make your helpers private functions.
http://www.mathworks.com/help/matlab/matlab_prog/private-functions.html
If they are used by many files in different directories, or if your tests
must live in a different directory, consider putting your helpers in a
package directory.
http://www.mathworks.com/help/matlab/matlab_oop/scoping-classes-with-packages.html
While this documentation is in the object-oriented section of the
documentation, packages are not limited to use only with MATLAB classdef
files. You can store plain functions in a package and use them as such.
A third, somewhat "hacky" way to test many small subfunctions in your main
file is to have a syntax that causes the main function to return a struct
array whose fields contain function handles to the subfunctions. Your tests
can then invoke the subfunctions using those function handles even though
the subfunctions are not in scope. As long as the subfunction was in scope
when the function handle was _created_ it doesn't matter if the subfunction
is out of scope when the function handle is _executed._
http://www.mathworks.com/help/matlab/matlab_prog/applications-of-function-handles.html#brf_1tn-1
--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com
|
|
|
|
