Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
Drexel University or The Math Forum.
|
|
dpb
Posts:
6,692
Registered:
6/7/07
|
|
Re: growdata and growdata2 - mathworks problem, still ?
Posted:
Oct 23, 2012 1:36 PM
|
|
On 10/23/2012 9:48 AM, someone wrote: ...
> 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. > ...
> > 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. ... > 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..." ...
Are you talking about memory internal to ODE45 or your application memory?
If the latter, _I'd_ think then if you're doing this kind of thing more than once (as you apparently are) you would fairly quickly learn what kind of memory growth to expect and could do the above pretty yourself specifically for your own situation.
Let your application use the brain you build into it to not allocate an element at a time... :)
I can see as Steven L says some special cases where the JIT compiler/code analyzer can do some special things but in general if you write code that isn't clever in it's memory usage I think it's both unreasonable and unfair to expect the compiler/TMW to take care of it for you automagically.
--
|
|
|
|