Thanks to visit codestin.com
Credit goes to github.com

Skip to content

1.5.0 final work #5353

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

Merged
merged 8 commits into from
Oct 29, 2015
Merged

1.5.0 final work #5353

merged 8 commits into from
Oct 29, 2015

Conversation

tacaswell
Copy link
Member

Branch I am dumping commits on as I start to do the release. I am re-writing the release guide as I go.

@tacaswell tacaswell added this to the next point release (1.5.0) milestone Oct 29, 2015
Copied from IPython commit 058dda2a8cfc39eaa2541300f577af95f2f407e5

Not bothering to customize the script, leaving IPython specific
documentation
ax.set_ylabel('memory size', color='r')
ax2.plot(coll_count, 'k')
ax2.set_ylabel('collect count', color='k')
fig.savefig('report')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this fix the leak, or just provide more info? In other words, should I try looking into this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just more information. I was checking that the memory increase is uniform (which it is 😞 )

I don't think it is all in one place either. Removing all of the plotting calls, and just making, saving, and closing the figures/axes results in a 3k/loop leak.

I am leaning towards this not blocking the release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose the real question is how much worse 1.5 is than 1.4.3... Even then, maybe not blockable -- some magical fix could always go into 1.5.1

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

running in in 1.4.3 now, but it looks just as bad (from eye balling the prints)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

py3.5, mpl 1.4.3: Average memory consumed per loop: 45.2139k bytes
py2.7, mpl 1.4.3: Average memory consumed per loop: 0.1642k bytes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe that explains why Python 3 always feels sluggish 👿

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Python 3 startup time is also much slower than python 2.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somehow, we need to make checking for memory leakage standard, not necessarily on every commit, but at least something that can be triggered weekly. In my opinion, memory leaks are such fundamental errors that they should have top priority for attention. Easy for me to say, though; tracking them down is not something for which I have much competence or time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the python version dependence strange, I thought the gc got better in 3...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably matters by your definition of "better". Better in keeping memory
under control while not causing much overhead, or better in keeping memory
usage to its smallest amounts?

On Thu, Oct 29, 2015 at 4:40 PM, Thomas A Caswell [email protected]
wrote:

In unit/memleak_hawaii3.py
#5353 (comment):

end = val
-print('Average memory consumed per loop: %1.4fk bytes\n' % ((end - start) / float(indEnd - indStart)))
+print('Average memory consumed per loop: %1.4fk bytes\n' %

  •  ((end - start) / float(indEnd - indStart)))
    
    +fig, ax = plt.subplots()
    +ax2 = ax.twinx()
    +ax.plot(mem_size, 'r')
    +ax.set_ylabel('memory size', color='r')
    +ax2.plot(coll_count, 'k')
    +ax2.set_ylabel('collect count', color='k')
    +fig.savefig('report')

I find the python version dependence strange, I thought the gc got
better in 3...


Reply to this email directly or view it on GitHub
https://github.com/matplotlib/matplotlib/pull/5353/files#r43441186.

@@ -8,7 +8,7 @@ For a list of all of the issues and pull requests since the last
revision, see the :ref:`github-stats`.

.. note::
matplotlib 1.5 supports Python 2.6, 2.7, 3.3, 3.4, and 3.5
matplotlib 1.5 supports Python 2.7, 3.4, and 3.5
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks

tacaswell added a commit that referenced this pull request Oct 29, 2015
@tacaswell tacaswell merged commit 6514211 into matplotlib:v1.5.x Oct 29, 2015
@tacaswell tacaswell deleted the 1.5.0_final_work branch October 29, 2015 21:18
@tacaswell
Copy link
Member Author

Should have the tag up in the next 15-30 min

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

Successfully merging this pull request may close these issues.

5 participants