Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #77683 > unrolled thread
| Started by | kjs <bfb@riseup.net> |
|---|---|
| First post | 2014-09-07 19:11 +0000 |
| Last post | 2014-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.
Re: weakref, memory management and execution slow down in PyQt4 kjs <bfb@riseup.net> - 2014-09-07 19:11 +0000
| From | kjs <bfb@riseup.net> |
|---|---|
| Date | 2014-09-07 19:11 +0000 |
| Subject | Re: 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. > >
Back to top | Article view | comp.lang.python
csiph-web