Re: Debugging reason for python running unreasonably slow when adding numbers

Il giorno lunedì 20 marzo 2023 alle 19:10:26 UTC+1 Thomas Passin ha scritto: > On 3/20/2023 11:21 AM, Edmondo Giovannozzi wrote: > > > >>> def sum1(): > >>> s = 0 > >>> for i in range(100): > >>> s += i > >>> return s > >>> > >>> def sum2(): > >>> return sum(range(100)) > >> Here

Re: Debugging reason for python running unreasonably slow when adding numbers

On 3/20/2023 11:21 AM, Edmondo Giovannozzi wrote: def sum1(): s = 0 for i in range(100): s += i return s def sum2(): return sum(range(100)) Here you already have the numbers you want to add. Actually using numpy you'll be much faster in this case: § imp

Re: Debugging reason for python running unreasonably slow when adding numbers

On 2023-03-20 15:21, Edmondo Giovannozzi wrote: > def sum1(): > s = 0 > for i in range(100): > s += i > return s > > def sum2(): > return sum(range(100)) Here you already have the numbers you want to add. Actually using numpy you'll be much faster in thi

Re: Debugging reason for python running unreasonably slow when adding numbers

> > def sum1(): > > s = 0 > > for i in range(100): > > s += i > > return s > > > > def sum2(): > > return sum(range(100)) > Here you already have the numbers you want to add. Actually using numpy you'll be much faster in this case: § import numpy as np § d

Re: Debugging reason for python running unreasonably slow when adding numbers

On 2023-03-15 17:09:52 +, Weatherby,Gerard wrote: > Sum is faster than iteration in the general case. I'd say this is the special case, not the general case. > def sum1(): > s = 0 > for i in range(100): > s += i > return s > > def sum2(): > return sum(range(10

Re: Debugging reason for python running unreasonably slow when adding numbers

Op 14/03/2023 om 8:48 schreef Alexander Nestorov: I have the following code: ... for i in range(151): # 150 iterations    ... Nothing to do with your actual question and it's probably just a small oversight, but still I thought it was worth a mention: that comment does not accu

Re: Debugging reason for python running unreasonably slow when adding numbers

.timeit(sum2, number=100)) --- For Loop Sum: 6.984986504539847 Built-in Sum: 0.5175364706665277 From: Weatherby,Gerard Date: Wednesday, March 15, 2023 at 1:09 PM To: python-list@python.org Subject: Re: Debugging reason for python running unreasonably slow when adding numbers Sum is faster t

Re: Debugging reason for python running unreasonably slow when adding numbers

Wednesday, March 15, 2023 at 11:46 AM To: python-list@python.org Subject: RE: Debugging reason for python running unreasonably slow when adding numbers *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. *** > Then I'm very confuse

RE: Debugging reason for python running unreasonably slow when adding numbers

> Then I'm very confused as to how things are being done, so I will shut > up. There's not enough information here to give performance advice > without actually being a subject-matter expert already. Short version: In this specific case "weights" is a 5,147 element list of floats, and "input" is

Re: Debugging reason for python running unreasonably slow when adding numbers

On Thu, 16 Mar 2023 at 02:14, Thomas Passin wrote: > > On 3/15/2023 11:01 AM, Chris Angelico wrote: > > On Thu, 16 Mar 2023 at 01:26, David Raymond > > wrote: > >> I'm not quite sure why the built-in sum functions are slower than the for > >> loop, > >> or why they're slower with the generator

Re: Debugging reason for python running unreasonably slow when adding numbers

On 3/15/2023 11:01 AM, Chris Angelico wrote: On Thu, 16 Mar 2023 at 01:26, David Raymond wrote: I'm not quite sure why the built-in sum functions are slower than the for loop, or why they're slower with the generator expression than with the list comprehension. For small-to-medium data sizes

Re: Debugging reason for python running unreasonably slow when adding numbers

On 3/15/2023 10:24 AM, David Raymond wrote: Or use the sum() builtin rather than reduce(), which was *deliberately* removed from the builtins. The fact that you can get sum() without importing, but have to go and reach for functools to get reduce(), is a hint that you probably shouldn't use reduc

Re: Debugging reason for python running unreasonably slow when adding numbers

On Thu, 16 Mar 2023 at 01:26, David Raymond wrote: > I'm not quite sure why the built-in sum functions are slower than the for > loop, > or why they're slower with the generator expression than with the list > comprehension. For small-to-medium data sizes, genexps are slower than list comps, bu

RE: Debugging reason for python running unreasonably slow when adding numbers

> Or use the sum() builtin rather than reduce(), which was > *deliberately* removed from the builtins. The fact that you can get > sum() without importing, but have to go and reach for functools to get > reduce(), is a hint that you probably shouldn't use reduce when sum > will work. Out of curios

Re: Debugging reason for python running unreasonably slow when adding numbers

On Tue, 14 Mar 2023 at 16:27, Alexander Nestorov wrote: > > I'm working on an NLP and I got bitten by an unreasonably slow behaviour in > Python while operating with small amounts of numbers. > > I have the following code: > > ```python > import random, time > from functools import reduce > > def

Re: Debugging reason for python running unreasonably slow when adding numbers

On Wed, 15 Mar 2023 at 08:53, Peter J. Holzer wrote: > > On 2023-03-14 16:48:24 +0900, Alexander Nestorov wrote: > > I'm working on an NLP and I got bitten by an unreasonably slow > > behaviour in Python while operating with small amounts of numbers. > > > > I have the following code: > [...] > >

Re: Debugging reason for python running unreasonably slow when adding numbers

On 2023-03-14 16:48:24 +0900, Alexander Nestorov wrote: > I'm working on an NLP and I got bitten by an unreasonably slow > behaviour in Python while operating with small amounts of numbers. > > I have the following code: [...] >       # 12x slower than equivalent JS >       sum_ = 0 >       for ke

Re: Debugging reason for python running unreasonably slow when adding numbers

On 3/14/2023 3:48 AM, Alexander Nestorov wrote: I'm working on an NLP and I got bitten by an unreasonably slow behaviour in Python while operating with small amounts of numbers. I have the following code: ```python import random, time from functools import reduce def trainPerceptron(perceptro

Re: Debugging Python C extensions with GDB

> On 14 Nov 2022, at 23:44, Jen Kris wrote: > >  > Thanks for your reply. Victor's article didn't mention ctypes extensions, so > I wanted to post a question before I build from source. Gdb works on any program its not special to python. Victor is only talking about a specific use of gdb

Re: Debugging Python C extensions with GDB

Thanks for your reply.  Victor's article didn't mention ctypes extensions, so I wanted to post a question before I build from source.  Nov 14, 2022, 14:32 by ba...@barrys-emacs.org: > > >> On 14 Nov 2022, at 19:10, Jen Kris via Python-list >> wrote: >> >> In September 2021, Victor Stinner w

Re: Debugging Python C extensions with GDB

> On 14 Nov 2022, at 19:10, Jen Kris via Python-list > wrote: > > In September 2021, Victor Stinner wrote “Debugging Python C extensions with > GDB” > (https://developers.redhat.com/articles/2021/09/08/debugging-python-c-extensions-gdb#getting_started_with_python_3_9). > > > My question

Re: Debugging automatic quotation in subprocess.Popen()

On 10/7/22, c.bu...@posteo.jp wrote: > > I need to improve my understanding about how subprocess.Popen() does > quote arguments. I have special case here. > > Simple example: > Popen(['ls', '-l']) results on a shell in "ls -l" without quotation. The shell is only used if Popen is instantiated wit

Re: Debugging automatic quotation in subprocess.Popen()

On Sat, 8 Oct 2022 at 08:24, wrote: > > Hello, > > I need to improve my understanding about how subprocess.Popen() does > quote arguments. I have special case here. > > Simple example: > Popen(['ls', '-l']) results on a shell in "ls -l" without quotation. > > Quotes are added if they are needed: >

Re: Debugging native cython module with visual studio toolchain

I can happily say I haven't used a Microsoft compiler/linker in decades, but: 1) Maybe clang-cl will do what you want? 2) Maybe it'd be easier to put debugging print's/printf's/cout <<'s in your code? HTH On Sat, Nov 14, 2020 at 1:55 PM Jeff wrote: > > > > Hi, > > > > We developed a Python modu

Re: Debugging a memory leak

Pasha Stetsenko wrote at 2020-10-23 11:32 -0700: > ... > static int my_init(PyObject*, PyObject*, PyObject*) { return 0; } > static void my_dealloc(PyObject*) {} I think, the `dealloc` function is responsible to actually free the memory area. I see for example: static void Spec_dealloc(Spec* se

Re: Debugging a memory leak

Thanks MRAB, this was it. I guess I was thinking about tp_dealloc as a C++ destructor, where the base class' destructor is called automatically. On Fri, Oct 23, 2020 at 11:59 AM MRAB wrote: > On 2020-10-23 19:32, Pasha Stetsenko wrote: > > Thanks for all the replies! > > Following Chris's advice

Re: Debugging a memory leak

On 2020-10-23 19:32, Pasha Stetsenko wrote: Thanks for all the replies! Following Chris's advice, I tried to reduce the code to the smallest reproducible example (I guess I should have done it sooner), but here's what I came up with: ``` #include #include static int my_init(PyObject*,

Re: Debugging a memory leak

Thanks for all the replies! Following Chris's advice, I tried to reduce the code to the smallest reproducible example (I guess I should have done it sooner), but here's what I came up with: ``` #include #include static int my_init(PyObject*, PyObject*, PyObject*) { return 0; } static voi

Re: Debugging a memory leak

Pasha Stetsenko wrote at 2020-10-22 17:51 -0700: > ... >I'm a maintainer of a python library "datatable" (can be installed from >PyPi), and i've been recently trying to debug a memory leak that occurs in >my library. >The program that exposes the leak is quite simple: >``` >import datatable as dt >

Re: Debugging a memory leak

> On Oct 22, 2020, at 5:51 PM, Pasha Stetsenko wrote: > > Dear Python gurus, > > I'm a maintainer of a python library "datatable" (can be installed from > PyPi), and i've been recently trying to debug a memory leak that occurs in > my library. > The program that exposes the leak is quite simp

Re: Debugging a memory leak

On Fri, Oct 23, 2020 at 12:20 PM Pasha Stetsenko wrote: > I'm currently not sure where to go from here. Is there something wrong with > my python object that prevents it from being correctly processed by the > Python runtime? Because this doesn't seem to be the usual case of > incrementing the ref

Re: Debugging technique

Another nice debugger feature is to step up with "u", this will take you to the parent frame where you can again inspect the variables. I use this when I want to reverse engineer how the interpreter got to a specific line. Maybe worth mentioning that Werkzeug provides in-browser interactive debug

Re: Debugging technique

This probably is not for you. But PyCharm has a panel that shows a stack trace. I created a video about debugging using the PyCharm debugger. Here is a YouTube link: https://www.youtube.com/watch?v=cxAOSQQwDJ4 Irv > On Oct 2, 2020, at 11:51 PM,

Re: Debugging technique

On 2020-10-03 8:58 AM, Chris Angelico wrote: On Sat, Oct 3, 2020 at 4:53 PM Frank Millman wrote: Hi all When debugging, I sometimes add a 'breakpoint()' to my code to examine various objects. However, I often want to know how I got there, so I replace the 'breakpoint()' with a '1/0', to forc

Re: Debugging technique

On Sat, Oct 3, 2020 at 4:53 PM Frank Millman wrote: > > Hi all > > When debugging, I sometimes add a 'breakpoint()' to my code to examine > various objects. > > However, I often want to know how I got there, so I replace the > 'breakpoint()' with a '1/0', to force a traceback at that point. Then I

Re: Debugging (was Re: Why not allow empty code blocks?)

On Fri, Aug 5, 2016 at 4:37 AM, Terry Reedy wrote: > Making repeat a keyword would have such an extremely high cost > that it is out of the question and not a sane proposal. > To start with, it is used in two major, widely used APIs. > > itertools.repeat + 50 uses in other itertools and tests > ti

Re: Debugging (was Re: Why not allow empty code blocks?)

Making repeat a keyword would have such an extremely high cost that it is out of the question and not a sane proposal. To start with, it is used in two major, widely used APIs. itertools.repeat + 50 uses in other itertools and tests + all the imports and and uses of repeat() in code all over th

Re: Debugging (was Re: Why not allow empty code blocks?)

On Thursday 04 August 2016 19:13, BartC wrote: > On 04/08/2016 04:23, Steven D'Aprano wrote: >> On Wed, 3 Aug 2016 08:16 pm, BartC wrote: > >>> So the idea that remembering 'repeat N' is a cognitive burden, and the >>> myriad string operations for example are not, is ridiculous. >> >> Who says it

Re: Debugging (was Re: Why not allow empty code blocks?)

On Thu, Aug 4, 2016 at 7:13 PM, BartC wrote: > On 04/08/2016 04:23, Steven D'Aprano wrote: >> >> On Wed, 3 Aug 2016 08:16 pm, BartC wrote: > > >>> So the idea that remembering 'repeat N' is a cognitive burden, and the >>> myriad string operations for example are not, is ridiculous. >> >> >> Who sa

Re: Debugging (was Re: Why not allow empty code blocks?)

On 04/08/2016 04:23, Steven D'Aprano wrote: On Wed, 3 Aug 2016 08:16 pm, BartC wrote: So the idea that remembering 'repeat N' is a cognitive burden, and the myriad string operations for example are not, is ridiculous. Who says it isn't a cognitive burden? Of course it is. The difference is

Re: Debugging (was Re: Why not allow empty code blocks?)

On Wed, 3 Aug 2016 08:16 pm, BartC wrote: > On 03/08/2016 06:43, Steven D'Aprano wrote: > >> Not everything that is done is worth the cognitive burden of memorising a >> special case. > > >> In some ways, Python is a more minimalist language than you like. That's >> okay, you're allowed to

Re: Debugging (was Re: Why not allow empty code blocks?)

On Wed, Aug 3, 2016 at 8:16 PM, BartC wrote: > On 03/08/2016 06:43, Steven D'Aprano wrote: > >> Not everything that is done is worth the cognitive burden of memorising a >> special case. > > > >> In some ways, Python is a more minimalist language than you like. That's >> okay, >> you're allow

Re: Debugging (was Re: Why not allow empty code blocks?)

On 03/08/2016 06:43, Steven D'Aprano wrote: Not everything that is done is worth the cognitive burden of memorising a special case. In some ways, Python is a more minimalist language than you like. That's okay, you're allowed to disagree with some design decisions. Well it's minimalist

Re: Debugging (was Re: Why not allow empty code blocks?)

On Wednesday 03 August 2016 05:14, BartC wrote: > It's fundamental in that, when giving instructions or commands in > English, it frequently comes up when you want something done a set > number of times: > > "Give me 20 push-ups" At which point the person will invariable drop to the ground and s

Re: Debugging (was Re: Why not allow empty code blocks?)

On 02/08/2016 22:27, Terry Reedy wrote: On 8/2/2016 7:05 AM, BartC wrote: Your objection to a feature such as 'repeat N' doesn't really stack up. My objection is that there is a real cost that MUST be stacked up against the benefit. ... Anyway, if that was a valid objection, it would apply

Re: Debugging (was Re: Why not allow empty code blocks?)

Terry Reedy writes: > I think it is you who is unwilling to admit that nearly everything > that would be useful also has a cost, and that the ultimate cost of > adding every useful feature, especially syntax features, would be to > make python less unusable. I think you meant "usable" ;). Some o

Re: Debugging (was Re: Why not allow empty code blocks?)

On 8/2/2016 7:05 AM, BartC wrote: On 31/07/2016 19:58, Terry Reedy wrote: On 7/31/2016 6:18 AM, BartC wrote: repeat N: The benefit is not so much performance, but being able to express something very easily and quickly. The cost of the 'repeat' contraction is that one cannot use the loo

Re: Debugging (was Re: Why not allow empty code blocks?)

On Wed, Aug 3, 2016 at 5:55 AM, Christian Gollwitzer wrote: >> - Arbitrary-precision non-integers > > > https://pypi.python.org/pypi/bigfloat/ > > ? Wasn't aware of that. Cool. Not that I need it very often (and when I do, I can use Pike, which has MPFR support built-in). Or I can use decimal.Dec

Re: Debugging (was Re: Why not allow empty code blocks?)

Am 02.08.16 um 16:58 schrieb Chris Angelico: - A more free-form declarative syntax for laying out GUI code Actually, the Tkinter wrapper misses one feature of grid in Tcl/Tk: You can write something like grid .a .b grid .c .d to lay out a GUI 2x2 grid using "ASCII-art". There is a package i

Re: Debugging (was Re: Why not allow empty code blocks?)

On Wed, Aug 3, 2016 at 3:57 AM, Steven D'Aprano wrote: > On Wed, 3 Aug 2016 03:12 am, BartC wrote: > >> That's not a fundamental language feature. Repeat-N is. And if properly >> designed, isn't an extra feature at all but a special case of a generic >> loop. > > Which means it is NOT a fundamenta

Re: Debugging (was Re: Why not allow empty code blocks?)

On 02/08/2016 18:57, Steven D'Aprano wrote: On Wed, 3 Aug 2016 03:12 am, BartC wrote: That's not a fundamental language feature. Repeat-N is. And if properly designed, isn't an extra feature at all but a special case of a generic loop. Which means it is NOT a fundamental language feature. "R

Re: Debugging (was Re: Why not allow empty code blocks?)

On Wed, 3 Aug 2016 03:12 am, BartC wrote: > That's not a fundamental language feature. Repeat-N is. And if properly > designed, isn't an extra feature at all but a special case of a generic > loop. Which means it is NOT a fundamental language feature. "Repeat N without tracking the loop variable

Re: Debugging (was Re: Why not allow empty code blocks?)

On 02/08/2016 15:58, Chris Angelico wrote: On Tue, Aug 2, 2016 at 9:05 PM, BartC wrote: I think the real reason is not willing to admit that the language lacks something that could actually be useful, and especially not to an upstart on usenet who is not even an expert in that language. I kno

Re: Debugging (was Re: Why not allow empty code blocks?)

On Tue, Aug 2, 2016 at 9:05 PM, BartC wrote: > I think the real reason is not willing to admit that the language lacks > something that could actually be useful, and especially not to an upstart on > usenet who is not even an expert in that language. I know what features I miss from the languages

Re: Debugging (was Re: Why not allow empty code blocks?)

On 31/07/2016 19:58, Terry Reedy wrote: On 7/31/2016 6:18 AM, BartC wrote: repeat N: The benefit is not so much performance, but being able to express something very easily and quickly. The cost of the 'repeat' contraction is that one cannot use the loop variable, either as part of a mod

Re: Debugging (was Re: Why not allow empty code blocks?)

On Mon, Aug 1, 2016 at 4:58 AM, Terry Reedy wrote: > > As for the original topic: Guido judged that a uniform rule "Compound > statement headers end with ':' and the next line has an additional indent" > would make correct code easier to write and parse and make it visually more > obvious. Some P

Re: debugging uwsgi

On 08/01/2016 15:03, Robin Becker wrote: I have an unusual bug in a large django project which has appeared when using nginx + uwsgi + django. The configuration nginx + flup + django or the django runserver don't seem to create the conditions for the error. Basically I am seeing an error Trace

Re: debugging during package development

On Sat, 01 Aug 2015 15:30:34 +1000, Ben Finney wrote: > Seb writes: >> With lots of debugging to do, the last thing I'd want is to worry >> about the search path. > Short answer: you need ‘python3 ./setup.py develop’. > Medium-length answer: you need to add some infrastructure to get your > pr

Re: debugging during package development

On 8/1/2015 12:21 AM, Seb wrote: It seems too cumbersome to have to update `sys.path` to include the development tree of a package (and sub-packages) that's still very young. With lots of debugging to do, the last thing I'd want is to worry about the search path. So I've been searching for bet

Re: debugging during package development

Seb writes: > It seems too cumbersome to have to update `sys.path` to include the > development tree of a package (and sub-packages) that's still very > young. With lots of debugging to do, the last thing I'd want is to > worry about the search path. So I've been searching for better ways to >

Re: debugging during package development

Seb writes: > With lots of debugging to do, the last thing I'd want is to worry > about the search path. Short answer: you need ‘python3 ./setup.py develop’. Medium-length answer: you need to add some infrastructure to get your project to the point where you can run ‘python3 ./setup.py develop’

Re: debugging on windows

. Unhandled exception at 0x1e0aebb8 in python.exe: 0xC005: Access violation reading location 0x0048. This is a C level error -- likely some memory corruption. You will need a C level debugger to analyse the problem - and likely, it will not be easy. indeed it was. Seem

Re: debugging on windows

Robin Becker writes: > Using > >> Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit >> (Intel)] on win32 >> Type "help", "copyright", "credits" or "license" for more information. > > to run a tkinter + pmw2 application I have the following error on windows xp > sp3 >

Re: Debugging on the Mac question.

PETER, thanks Peter, I have already found the PDB module and have had a play with it. It will do for now. On 03/01/2014, at 8:08 PM, Paul Rudin wrote: > Sean Murphy writes: > > >> I am a Vision Impaired programmer on the Mac and Window platforms. I have >> started to learn Python. The bigges

Re: Debugging on the Mac question.

On 2014-01-03 04:17, Sean Murphy wrote: Team, I am a Vision Impaired programmer on the Mac and Window platforms. I have started to learn Python. The biggest road block I have is the ability of debugging my simple scripts. The IDLE program does not work with the screen readers I use on the Ma

Re: Debugging on the Mac question.

Sean Murphy writes: > I am a Vision Impaired programmer on the Mac and Window platforms. I have > started to learn Python. The biggest road block I have is the ability of > debugging my simple scripts. The IDLE program does not work with the screen > readers I use on the Mac or Windows. A screen

Re: Debugging decorator

On Sun, Nov 3, 2013 at 9:55 PM, Jason Friedman wrote: > >> I wrote this decorator: https://gist.github.com/yasar11732/7163528 >> > I ran it with Python 2 and thought it was neat. > Most of my work is Python 3. > I ran 2to3-3.3 against it and I am getting this error: > > $ ./simple.py > Traceback (

Re: Debugging decorator

On Mon, Nov 4, 2013 at 12:20 AM, Chris Angelico wrote: > As print is now a function, you're going to need to construct a > function call element instead of a special 'print' node. I don't know > how to do that as I'm not an AST expert, but hopefully you can work it > out from there? > > If you nee

Re: Debugging decorator

> I wrote this decorator: https://gist.github.com/yasar11732/7163528 > > I ran it with Python 2 and thought it was neat. Most of my work is Python 3. I ran 2to3-3.3 against it and I am getting this error: $ ./simple.py Traceback (most recent call last): File "./simple.py", line 3, in @debug

Re: Debugging decorator

On Mon, Oct 28, 2013 at 11:43 PM, Schneider wrote: > 2. In the case of an assignment (but holds for the return statement too). > think about the following code: > > a = 0 > @debugging > def foo(): > a = a + 1 > > def bar(): > #assign something else to a > > Imagine foo() and bar() being c

Re: Debugging decorator

On 10/26/2013 01:55 AM, Yaşar Arabacı wrote: Hi people, I wrote this decorator: https://gist.github.com/yasar11732/7163528 When this code executes: @debugging def myfunc(a, b, c, d = 48): a = 129 return a + b print myfunc(12,15,17) This is printed: fun

Re: Debugging decorator

On 10/25/2013 7:55 PM, Yaşar Arabacı wrote: Hi people, I wrote this decorator: https://gist.github.com/yasar11732/7163528 wow, this looks really powerful. I would like to add the ability to associate a tag or set of tags with the decorator so that the debug output only happens when there is

Re: Debugging decorator

On Sat, Oct 26, 2013 at 10:55 AM, Yaşar Arabacı wrote: > I think I can be used instead of inserting and deleting print > statements when trying to see what is > passed to a function and what is assingned to what etc. I think it can > be helpful during debugging. > > It works by rewriting ast of th

Re: Debugging memory leaks

"writeson" wrote in message news:09917103-b35e-4728-8fea-bcb4ce2bd...@googlegroups.com... > Hi all, > > I've written a program using Twisted that uses SqlAlchemy to access a > database using threads.deferToThread(...) and SqlAlchemy's > scoped_session(...). This program runs for a long time, b

Re: Debugging memory leaks

Chris Angelico writes: > ... > Right. Everything needs to be scaled. Everything needs to be in > perspective. Losing 1 kilobit per day is indeed trivial; even losing > one kilobyte per day, which is what I assume you meant :), isn't > significant. But it's not usually per day, it's per leaking act

Re: Debugging memory leaks

On Sat, Jun 15, 2013 at 9:35 PM, rusi wrote: > On Jun 15, 4:23 pm, Ben Finney wrote: >> rusi writes: >> > On Jun 15, 5:16 am, Ben Finney wrote: >> > > Is a web browser a “typical desktop app”? A filesystem browser? An >> > > instant messenger? A file transfer application? A podcatcher? All of >

Re: Debugging memory leaks

On Jun 15, 4:23 pm, Ben Finney wrote: > rusi writes: > > On Jun 15, 5:16 am, Ben Finney wrote: > > > Is a web browser a “typical desktop app”? A filesystem browser? An > > > instant messenger? A file transfer application? A podcatcher? All of > > > those typically run for months at a time on my

Re: Debugging memory leaks

rusi writes: > On Jun 15, 5:16 am, Ben Finney wrote: > > Is a web browser a “typical desktop app”? A filesystem browser? An > > instant messenger? A file transfer application? A podcatcher? All of > > those typically run for months at a time on my desktop. > > > > Any memory leak in any of those

Re: Debugging memory leaks

On Sat, Jun 15, 2013 at 4:52 PM, dieter wrote: > Chris Angelico writes: > >> ... >> It's terrible advice in generality, because it encourages a sloppiness >> of thinking: "Memory usage doesn't matter, we'll just instruct people >> to reset everything now and then". > > "Memory usage" may matter.

Re: Debugging memory leaks

Chris Angelico writes: > ... > It's terrible advice in generality, because it encourages a sloppiness > of thinking: "Memory usage doesn't matter, we'll just instruct people > to reset everything now and then". "Memory usage" may matter. But if you loose 1 kb a day, your process can run 3 years

Re: Debugging memory leaks

On Jun 15, 5:16 am, Ben Finney wrote: > rusi writes: > > On Jun 14, 1:15 am, Giorgos Tzampanakis > > wrote: > > > Am I the only one who thinks this is terrible advice? > > > I would expect a typical desktop app to run for a couple of hours -- > > maybe a couple of days. > > Is a web browser a “t

Re: Debugging memory leaks

On Fri, 14 Jun 2013 22:57:24 +, Giorgos Tzampanakis wrote: > On 2013-06-14, Steven D'Aprano wrote: > >> On Thu, 13 Jun 2013 20:15:42 +, Giorgos Tzampanakis wrote: >> Therefore: if the leak seems to be small, it may be much more advicable to restart your process periodically (dur

Re: Debugging memory leaks

rusi writes: > On Jun 14, 1:15 am, Giorgos Tzampanakis > wrote: > > Am I the only one who thinks this is terrible advice? > > I would expect a typical desktop app to run for a couple of hours -- > maybe a couple of days. Is a web browser a “typical desktop app”? A filesystem browser? An instant

Re: Debugging memory leaks

On Fri, Jun 14, 2013 at 11:53 PM, rusi wrote: > On Jun 14, 1:15 am, Giorgos Tzampanakis > wrote: >> Am I the only one who thinks this is terrible advice? > > I would expect a typical desktop app to run for a couple of hours -- > maybe a couple of days. > Living with a small (enough) leak there ma

Re: Debugging memory leaks

On 2013-06-14, Steven D'Aprano wrote: > On Thu, 13 Jun 2013 20:15:42 +, Giorgos Tzampanakis wrote: > >>> Therefore: if the leak seems to be small, it may be much more advicable >>> to restart your process periodically (during times where a restart does >>> not hurt much) rather than try to fin

Re: Debugging memory leaks

On Jun 14, 1:15 am, Giorgos Tzampanakis wrote: > Am I the only one who thinks this is terrible advice? I would expect a typical desktop app to run for a couple of hours -- maybe a couple of days. Living with a small (enough) leak there may be ok. [In particular I believe that most commercial apps

Re: Debugging memory leaks

On Jun 13, 6:24 am, writeson wrote: > Anyway, my real question is how to go about debugging memory leak problems in > Python, particularly for a long running > server process written with Twisted. I'm not sure how to use heapy or guppy, > and objgraph doesn't tell me enough to > locate the probl

Re: Debugging memory leaks

On Fri, Jun 14, 2013 at 12:40 PM, Steven D'Aprano wrote: > On Thu, 13 Jun 2013 20:15:42 +, Giorgos Tzampanakis wrote: > >>> Therefore: if the leak seems to be small, it may be much more advicable >>> to restart your process periodically (during times where a restart does >>> not hurt much) rat

Re: Debugging memory leaks

On Thu, 13 Jun 2013 20:15:42 +, Giorgos Tzampanakis wrote: >> Therefore: if the leak seems to be small, it may be much more advicable >> to restart your process periodically (during times where a restart does >> not hurt much) rather than try to find (and fix) the leaks. Only when >> the leak

Re: Debugging memory leaks

On Fri, Jun 14, 2013 at 6:15 AM, Giorgos Tzampanakis wrote: > On 2013-06-13, dieter wrote: >> Therefore: if the leak seems to be small, it may be much more advicable >> to restart your process periodically (during times where a restart does >> not hurt much) rather than try to find (and fix) the l

Re: Debugging memory leaks

Giorgos Tzampanakis wrote: >On 2013-06-13, dieter wrote: > >>> ... Anyway, my real question is how to go about debugging memory >leak >>> problems in Python, particularly for a long running server process >>> written with Twisted. I'm not sure how to use heapy or guppy, and >>> objgraph doesn't

Re: Debugging memory leaks

On 2013-06-13, dieter wrote: >> ... Anyway, my real question is how to go about debugging memory leak >> problems in Python, particularly for a long running server process >> written with Twisted. I'm not sure how to use heapy or guppy, and >> objgraph doesn't tell me enough to locate the problem

Re: Debugging memory leaks

On 06/13/2013 02:07 PM, writeson wrote: Dieter, Thanks for the response, and you're correct, debugging memory leaks is tough! So far I haven't had much luck other than determining I have a leak. I've used objgraph to see that objects are being created that don't seem to get cleaned up. What I

Re: Debugging memory leaks

Dieter, Thanks for the response, and you're correct, debugging memory leaks is tough! So far I haven't had much luck other than determining I have a leak. I've used objgraph to see that objects are being created that don't seem to get cleaned up. What I can't figure out so far is why, they are

Re: Debugging memory leaks

writeson writes: > ... > Anyway, my real question is how to go about debugging memory leak problems in > Python, particularly for a long running server process written with Twisted. > I'm not sure how to use heapy or guppy, and objgraph doesn't tell me enough > to locate the problem. Analysin

Re: Debugging parallel nose tests?

- Original Message - > In article , > Dave Angel wrote: > > > On 05/23/2013 09:09 AM, Roy Smith wrote: > > > > > > > > > > > > nosetests --process-timeout=60 --processes=40 test_api.py > > > > > > > Do you have a 40-processor system? > > No, but many of the tests are I/O bound.

Re: Debugging parallel nose tests?

In article , Roy Smith wrote: > Is there some way to make nose print a report of how it partitioned the > tests across the various processes? I never found such a feature, but I did figure out a way to do what I needed. We use a system of unique id's to track HTTP requests through our syste

Re: Debugging parallel nose tests?

On May 24, 2013, at 5:05 AM, Jean-Michel Pichavant wrote: > - Original Message - >> In article , >> Dave Angel wrote: >> >>> On 05/23/2013 09:09 AM, Roy Smith wrote: nosetests --process-timeout=60 --processes=40 test_api.py >>> >>> Do you have a 40-proc

Re: Debugging parallel nose tests?

In article , Dave Angel wrote: > On 05/23/2013 09:09 AM, Roy Smith wrote: > > > > > > > > nosetests --process-timeout=60 --processes=40 test_api.py > > > > Do you have a 40-processor system? No, but many of the tests are I/O bound. > And do you have enough RAM to run all of those proces

Re: Debugging parallel nose tests?

On 05/23/2013 09:09 AM, Roy Smith wrote: nosetests --process-timeout=60 --processes=40 test_api.py Do you have a 40-processor system? And do you have enough RAM to run all of those processes? -- DaveA -- http://mail.python.org/mailman/listinfo/python-list

  1   2   3   >