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

Memory #24

Open
henrikbjorn opened this issue Feb 16, 2014 · 5 comments
Open

Memory #24

henrikbjorn opened this issue Feb 16, 2014 · 5 comments

Comments

@henrikbjorn
Copy link
Contributor

If you have a lot of iterations memory skyrockets when used. Maybe results could be temp saved in a file somewhere when doing the calculations?

@staabm
Copy link
Contributor

staabm commented Feb 16, 2014

How many iterations do you use?

@henrikbjorn
Copy link
Contributor Author

1.000.000

@staabm
Copy link
Contributor

staabm commented Feb 16, 2014

Do you see an obvious benefit when using that much iterations? We use most of the time 1000-10000 iterations which results in rather stable results...

@henrikbjorn
Copy link
Contributor Author

None other that i could and the output have a lot of space for the iterations number :)

@polyfractal
Copy link
Owner

Heya, sorry for the delay. I'd tend to agree with @staabm, there really isn't any benefit to more iterations once the timings start to stabilize.

That said, memory usage could be improved -- the fact that it bloats up is not terribly surprising. Athletic stores everything in a hash which will just keep growing.

A new SuiteRunner and ClassRunner could be implemented, which stream results to disk as they arrive. Then when it comes to publishing, instead of sending the entire result set, it could incrementally call publish() with fragments...effectively giving a streaming interface without introducing the complexity of a generator or passing around file handles.

PRs welcome :)

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

No branches or pull requests

3 participants