Date: Oct 23, 2012 10:48 AM
Author: text-dude
Subject: Re: growdata and growdata2 - mathworks problem, still ?

On 2012-10-23 15:41, Steven_Lord wrote:>
>
> "someone" <newsboost@gmail.com> wrote in message
> news:k665s0$eg2$1@dont-email.me...

>> Hi,
>>
>> This is from 2007:
>>
>> http://www.mathworks.com/matlabcentral/fileexchange/8334
>>
>>
>> Is it still necessary/advisable/required to do something like
>> "growdata" if you want a speed increase and have (very) long
>> increasing arrays ?

>
> It is impossible to answer that question without knowing the specific
> way your code is written.


I have a lot of calls to ODE45 and then I save a lot of things to some
global growing arrays, both growing vectors, growing matrices and
growing cell arrays. After the timeloop ends, I investigate the results
using data from inside ODE45.

By the way, not all calls from ODE45 are full timesteps so I'm wasting
some space here (AFAIR it takes about 5 function calls to compute 1
timestep so my global saving-stuff-arrays are actually 5 times bigger
than necessary and they are *big*, due to small timestep)... My current
simulations use approx 6 GB of memory (and I don't save all, only the
most important things).

>> Or did Mathworks see this problem and fixed the problem by using a
>> clever compiler that automatically optimizes its way out of this

problem?
>
> In release R2011a there is an entry in the Release Notes that reads:
>
> "This release improves the performance of growing an array in the
> trailing dimension if that array has not been preallocated."


I can see from my progress monitor (= own Matlab-code), that the
estimate for finishing the calculation gets bigger and bigger. Either it
means the problem is more and more difficult (needs smaller timesteps)
or it's because of the growing arrays-stuff (hence question about using
growdata).

>> I'm asking, because I have a program and it LOOKS to me, like the
>> problem still persists. So I think maybe I should use growdata now...
>> What do you think, mr. Steven Lord or others ?

>
> Try to preallocate first. If that doesn't improve the performance, or if


But I don't know how big I should preallocate to before, using ODE45.
It's impossible to say.

> you can't do that for some other reason, send a section of code for
> which you believe you'll need to use GROWDATA on to Technical Support so
> they can investigate if there's additional improvement the development
> staff can make to how arrays are grown in MATLAB.


My code is big. If I had a specific problem that not so many people
have, I would like to contact tech support. However, this is such a
typical problem, for people using ode45 (I guess) so I hope to hear a
few people's own experiences with later matlab versions.

But *I* think that the matlab compiler should be clever enough to see
and think that:

"hey! there's an array that keeps growing bigger and bigger. Even though
the user didn't ask me, then: Let me use the brain my developers at
mathworks gave me and then maybe don't preallocate a single array
element at a time, but preallocate some extra elements based on a clever
guess I've learned - to save time allocating data the whole time..."

?