Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inefficient memory usage #72

Open
z2v opened this issue Nov 21, 2014 · 4 comments
Open

Inefficient memory usage #72

z2v opened this issue Nov 21, 2014 · 4 comments
Labels

Comments

@z2v
Copy link
Collaborator

z2v commented Nov 21, 2014

While preparing data to be returned to Python, function PackOut (PyDSTool/integrator/interface.c) makes a copy of all computed data and doubles amount of used memory as a result.

@z2v z2v added the bug label Nov 21, 2014
@robclewley
Copy link
Owner

@z2v Do you know that it's safe to not copy based on possible need for the original data at a later time? For instance, could the returned data be changed in the interface or in python and affect the contents of the solver that might be needed e.g. for continuing an orbit?

@z2v
Copy link
Collaborator Author

z2v commented Apr 28, 2015

@robclewley, AFAIK, both radau and dopri are single-step methods and previously computed trajectory data is not used in solvers.

@robclewley
Copy link
Owner

We can test it without the memory copy, then. My only concern is something like compute's continue integration option, but we have a test for that use case.

@robclewley
Copy link
Owner

It makes me nervous because it has been almost 10 years since the interface was written by my colleague, and I feel like there could have been a reason that I no longer remember. But since we are keeping a record of this discussion, we might as well try taking out the copy and testing the result. I can also see if I need to think up further tests than we already have to check that all is well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants