Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #77683 > unrolled thread

Re: weakref, memory management and execution slow down in PyQt4

Started bykjs <bfb@riseup.net>
First post2014-09-07 19:11 +0000
Last post2014-09-07 19:11 +0000
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: weakref, memory management and execution slow down in PyQt4 kjs <bfb@riseup.net> - 2014-09-07 19:11 +0000

#77683 — Re: weakref, memory management and execution slow down in PyQt4

Fromkjs <bfb@riseup.net>
Date2014-09-07 19:11 +0000
SubjectRe: weakref, memory management and execution slow down in PyQt4
Message-ID<mailman.13851.1410117255.18130.python-list@python.org>

[Multipart message — attachments visible in raw view] — view raw

Antoine Pitrou:
> kjs <bfb <at> riseup.net> writes:
>>
>> I have come to believe that the growing number of weakrefs is slowing
>> down execution. Is my analysis misguided? How can I introspect further?
>> If the slowdown can be attributed to weakref escalation, what are some
>> next steps?
> 
> The way to analyze this is to build some gradually smaller subsets of your
> application until you can isolate what is causing the growth in number of
> objects (if any). I would suggest first remove the GUI and replace it with
> some dummy functions, to stress your core logic.

Thanks for the advice. I commented out the graph generation and PyQt call

>>> self.app.processEvents()

where in the class __init__

>>> self.app = QtGui.QApplication(sys.argv)

This stopped the weakref proliferation. All other objects grow and
shrink in number as expected.

> 
> Note that "top" isn't a very reliable tool, as memory fragmentation and
> other factors can cause your process' visible size to grow even though
> Python's memory consumption may be stable. There are dedicated Python tools
> for finer analysis, such as tracemalloc, which is standard on 3.4 and available
> as a backport for older versions:
> 
> https://docs.python.org/3/library/tracemalloc.html
> http://pytracemalloc.readthedocs.org/
> 
> But regardless of such tools, the approach above (try to decompose your
> workload into separate parts until your find the culprit) is highly recommended.
> 
> Regards
> 
> Antoine.
> 
> 

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web