The rest of the information is also stored in the mat-file. What you are seeing is the size of the function handle itself, not everything it encapsulates.

As for pre-allocation, that would be nice, and it might help performance, especially if I chunked it up - but it can’t solve everything as we don’t know how big to make it. Whether or not that slows things down materially depends on the very picky details of how it gets called and how much and how often the array is grown.

For the example, it was going to make things muddier and harder to understand, I think, to write the chunked memory version.

–Loren

It is an interesting usage of nested function. Two questions:

1. After complete all calls and save f to a mat file, then clear whole workspace. Now, load the mat file and check with whos, the function handle, f only occupies 16 bytes. But check with s=functions(f), and s.workspace{1} all information is still there. I worder where the information is stored?

2. In the inner function, x and y are not pre-allocated. Will this affect the performance when the sizes of x and y becomes large?

-Yi

inner itself doesn’t retain the values. The function handle to the nested function does. All related get cleared up when the last reference to the nested function is cleared. However, local variables in inner get cleared right after each time it is run. Only x and y are retained with the nested function handle.

–Loren

Performance aside (though it is a legitimate question), persistent doesn’t easily allow multiple instantiations, for example, 2 gui screens, while nested functions allow this naturally.

–Loren

Had a quick look at this myself… It seems that with largish arrays (e.g. 1000×1000), the options are much the same, but that with smaller arrays (e.g. 100×100) persistent is slower than nested, with the persistent declaration line itself being one of the slower lines in the profile.

I can’t think of any good reasons for this, but it looks to me like nested beats persistent in any case, as well as allowing you to have multiple instances.

Hope that’s of interest to someone (and that maybe Loren or someone else can suggest reasons why persistent isn’t better)

Ged

> With persistent, you only have one instance

This is an obvious advantage for nested functions when multiple copies are useful, but how do the two options compare when both are feasible? In terms of speed, etc?

Instead of memoising, I have lots of data which I run a computationally intensive function on, parts of which are invariant to some aspects of the particular data. I can use either persistent variables or nested functions to store partial results for the invariant parts, speeding up the function for further calls on remaining data. Alternatively, I could use other functions to compute the invariant parts and simply pass these in to a different function.

I expected the first option (persistence) to be much quicker than the third (passing) since no memory needs to be copied back and forth, but I note on profiling that the persistent line itself seems to be quite a slow part of the code (when repeated over many data). I hadn’t considered the second option (nesting) at all; I wonder if it might be quicker than persistence… If so, why? Persistent arrays seem like a concept that should map efficiently to the lower level implementation, while nested functions keeping track of their own workspaces sounds more complex.

Many thanks,
Ged

The use of nested functions requires a lot of discipline and due to that is very error-prone, especially when different people work on the same code.