Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #46708 > unrolled thread
| Started by | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| First post | 2013-06-02 10:04 -0700 |
| Last post | 2013-06-03 15:11 -0400 |
| Articles | 9 on this page of 109 — 26 participants |
Back to article view | Back to comp.lang.python
PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 10:04 -0700
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 03:20 +1000
Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-02 17:49 +0000
Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 11:18 -0700
Re: PyWart: The problem with "print" Ned Batchelder <ned@nedbatchelder.com> - 2013-06-02 16:45 -0400
Re: PyWart: The problem with "print" Michael Torrie <torriem@gmail.com> - 2013-06-02 23:49 -0600
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 17:17 +1000
Re: PyWart: The problem with "print" Alister <alister.ware@ntlworld.com> - 2013-06-03 08:01 +0000
Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 11:09 -0700
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-02 19:03 +0000
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 06:21 +1000
Re: PyWart: The problem with "print" jmfauth <wxjmfauth@gmail.com> - 2013-06-04 05:23 -0700
Re: PyWart: The problem with "print" rusi <rustompmody@gmail.com> - 2013-06-04 06:29 -0700
Re: PyWart: The problem with "print" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-04 14:35 +0100
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-05 05:03 +0000
Re: PyWart: The problem with "print" Andrew Berg <robotsondrugs@gmail.com> - 2013-06-02 12:30 -0500
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 03:34 +1000
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-02 18:58 +0000
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 06:28 +1000
Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-03 18:37 -0700
Re: PyWart: The problem with "print" Vito De Tullio <vito.detullio@gmail.com> - 2013-06-04 05:16 +0200
Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-03 20:53 -0700
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-04 04:30 +0000
Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-04 05:39 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 08:44 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 02:00 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 09:19 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 02:27 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-05 05:28 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-04 22:31 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ned Batchelder <ned@nedbatchelder.com> - 2013-06-04 13:25 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 09:09 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-04 18:31 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Fábio Santos <fabiosantosart@gmail.com> - 2013-06-04 17:10 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Jason Swails <jason.swails@gmail.com> - 2013-06-04 13:32 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-04 11:42 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 16:21 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-05 00:37 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-04 23:28 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-04 23:11 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 17:15 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 00:47 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 09:49 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 02:59 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Dan Stromberg <drsalists@gmail.com> - 2013-06-06 18:26 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-05 09:59 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 09:15 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 02:59 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 14:59 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 01:56 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 12:29 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 21:25 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-06 00:06 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 09:29 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 19:45 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Serhiy Storchaka <storchaka@gmail.com> - 2013-06-06 14:12 +0300
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Robert Kern <robert.kern@gmail.com> - 2013-06-06 16:35 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:41 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Robert Kern <robert.kern@gmail.com> - 2013-06-06 17:08 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 10:27 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-06 14:44 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 10:59 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 17:53 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 18:44 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 19:03 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 22:01 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-07 02:29 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 20:14 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 20:24 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 20:30 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 20:43 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-06 11:08 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 08:49 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 02:00 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Grant Edwards <invalid@invalid.invalid> - 2013-06-06 17:32 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 01:37 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 11:45 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 07:09 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:26 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 08:36 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:46 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 11:03 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 11:11 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Terry Jan Reedy <tjreedy@udel.edu> - 2013-06-05 12:10 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-05 17:18 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 16:52 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-05 19:20 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 09:24 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-06 12:39 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 17:55 -0700
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-04 17:30 +1000
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-02 20:16 -0400
Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-03 03:10 +0000
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-02 23:23 -0400
Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-03 04:20 +0000
Re: PyWart: The problem with "print" Robert Kern <robert.kern@gmail.com> - 2013-06-03 11:52 +0100
Re: PyWart: The problem with "print" Tim Delaney <timothy.c.delaney@gmail.com> - 2013-06-03 13:37 +1000
Python Heisenbugs? (was: Re: PyWart: The problem with "print") Dan Sommers <dan@tombstonezero.net> - 2013-06-03 04:34 +0000
Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print") Chris Angelico <rosuav@gmail.com> - 2013-06-03 15:05 +1000
Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print") Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-03 03:06 -0400
Re: PyWart: The problem with "print" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-03 09:49 +0100
Re: PyWart: The problem with "print" Dave Angel <davea@davea.name> - 2013-06-03 08:56 -0400
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 12:02 +1000
Re: PyWart: The problem with "print" Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-03 11:12 -0600
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:09 -0400
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-03 20:31 +0000
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-04 06:44 +1000
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:10 -0400
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:11 -0400
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-06-03 09:49 +0100 |
| Message-ID | <mailman.2586.1370249389.3114.python-list@python.org> |
| In reply to | #46756 |
On 03/06/2013 04:10, Dan Sommers wrote: > On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote: > >> ... If you don't believe me, you've never hit a bug that 'magically' >> disappears when you add a debugging print statement ;-). > > Ah, yes. The Heisenbug. ;-) > > We used to run into those back in the days of C and assembly language. > They're much harder to see in the wild with Python. > Strikes me it's a bit like problems when prototyping circuit boards. The card doesn't work, so you mount it on an extender card, problem goes away, remove extender card, problem reappears. Wash, rinse, repeat :) -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-03 08:56 -0400 |
| Message-ID | <mailman.2594.1370264236.3114.python-list@python.org> |
| In reply to | #46756 |
On 06/03/2013 04:49 AM, Mark Lawrence wrote: > On 03/06/2013 04:10, Dan Sommers wrote: >> On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote: >> >>> ... If you don't believe me, you've never hit a bug that 'magically' >>> disappears when you add a debugging print statement ;-). >> >> Ah, yes. The Heisenbug. ;-) >> >> We used to run into those back in the days of C and assembly language. >> They're much harder to see in the wild with Python. >> > > Strikes me it's a bit like problems when prototyping circuit boards. The > card doesn't work, so you mount it on an extender card, problem goes > away, remove extender card, problem reappears. Wash, rinse, repeat :) > That's when you use a little kappy-zapper spray. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-03 12:02 +1000 |
| Message-ID | <mailman.2572.1370224968.3114.python-list@python.org> |
| In reply to | #46708 |
On Mon, Jun 3, 2013 at 10:16 AM, Jason Swails <jason.swails@gmail.com> wrote:
> Copy-and-pasting your timeit experiment on my machine yields different
> timings (Python 2.7):
>
>>>> import sys
>>>> timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
>>>> DEBUG: return\n\tsys.stdout.write(*args)\nDEBUG=False',number=1000000)
> 0.15644001960754395
>
> which is ~150 ns/function call, versus ~1300 ns/function call. And there
> may be even more extreme examples, this is just one I was able to cook up
> quickly.
The exact time will of course vary enormously. My point still would
stand at 1300ns; it's still extremely low compared to many other
overheads.
> This is, I'm sad to say, where my alignment with RR ends. While I use
> prints in debugging all the time, it can also become a 'crutch', just like
> reliance on valgrind or gdb. If you don't believe me, you've never hit a
> bug that 'magically' disappears when you add a debugging print statement
> ;-).
Yes, I've had situations like that. They are, however, EXTREMELY rare
compared to the times when a bug magically becomes shallow when you
add a debugging print!
> The easiest way to eliminate these 'dead' calls is to simply comment-out the
> print call, but I would be quite upset if the interpreter tried to outsmart
> me and do it automagically as RR seems to be suggesting. And if you're
> actually debugging, then you typically only add a few targeted print
> statements -- not too hard to comment-out. If it is, and you're really that
> lazy, then by all means add a new, greppable function call and use a sed
> command to comment those lines out for you.
Yes. I also have high hopes for some of the cool AST manipulation
that's being developed at the moment; it should be relatively easy to
have a simple flag that controls whether debugprint (btw, I'd shorten
the name) represents code or no-code.
But consider all the other things that you probably do in your Python
programs. Every time you reference something as "module.name", you
require a lookup into the current module's namespace to find the
module name, then into that module's namespace to find the object you
want. Snagging names as locals is a common optimization, but is far
from universally applied. Why? Because the readability cost just isn't
worth it. We use Python because it is "fast enough", not because it
lets us squeeze every CPU cycle out of the code.
That said, I can often smoke Python with Pike, thanks to a few rather
cool optimizations (including looking up module names at compile time,
which reduces what I just said above). Maybe in the future some of
these optimizations will be done, I don't know. But for 99.9% of
Python scripts, you will *never* see the performance difference.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-06-03 11:12 -0600 |
| Message-ID | <mailman.2598.1370279576.3114.python-list@python.org> |
| In reply to | #46708 |
On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails <jason.swails@gmail.com> wrote: > I'm actually with RR in terms of eliminating the overhead involved with > 'dead' function calls, since there are instances when optimizing in Python > is desirable. I actually recently adjusted one of my own scripts to > eliminate branching and improve data layout to achieve a 1000-fold > improvement in efficiency (~45 minutes to 0.42 s. for one example) --- all > in pure Python. The first approach was unacceptable, the second is fine. > For comparison, if I add a 'deactivated' debugprint call into the inner loop > (executed 243K times in this particular test), then the time of the > double-loop step that I optimized takes 0.73 seconds (nearly doubling the > duration of the whole step). It seems to me that your problem here wasn't that the time needed for the deactivated debugprint was too great. Your problem was that a debugprint that executes 243K times in 0.73 seconds is going to generate far too much output to be useful, and it had no business being there in the first place. *Reasonably* placed debugprints are generally not going to be a significant time-sink for the application when disabled. > The easiest way to eliminate these 'dead' calls is to simply comment-out the > print call, but I would be quite upset if the interpreter tried to outsmart > me and do it automagically as RR seems to be suggesting. Indeed, the print function is for general output, not specifically for debugging. If you have the global print deactivation that RR is suggesting, then what you have is no longer a print function, but a misnamed debug function.
[toc] | [prev] | [next] | [standalone]
| From | Jason Swails <jason.swails@gmail.com> |
|---|---|
| Date | 2013-06-03 15:09 -0400 |
| Message-ID | <mailman.2603.1370286598.3114.python-list@python.org> |
| In reply to | #46708 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote: > On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails <jason.swails@gmail.com> > wrote: > > I'm actually with RR in terms of eliminating the overhead involved with > > 'dead' function calls, since there are instances when optimizing in > Python > > is desirable. I actually recently adjusted one of my own scripts to > > eliminate branching and improve data layout to achieve a 1000-fold > > improvement in efficiency (~45 minutes to 0.42 s. for one example) --- > all > > in pure Python. The first approach was unacceptable, the second is fine. > > For comparison, if I add a 'deactivated' debugprint call into the inner > loop > > (executed 243K times in this particular test), then the time of the > > double-loop step that I optimized takes 0.73 seconds (nearly doubling the > > duration of the whole step). > > It seems to me that your problem here wasn't that the time needed for > the deactivated debugprint was too great. Your problem was that a > debugprint that executes 243K times in 0.73 seconds is going to > generate far too much output to be useful, and it had no business > being there in the first place. *Reasonably* placed debugprints are > generally not going to be a significant time-sink for the application > when disabled. Well in 'debug' mode I wouldn't use an example that executed the loop 200K times -- I'd find one that executed a manageable couple dozen, maybe. When 'disabled,' the print statement won't do anything except consume clock cycles and potentially displace useful cache (the latter being the more harmful, since most applications are bound by the memory bus). It's better to eliminate this dead call when you're not in 'debugging' mode. (When active, it certainly would've taken more than 0.73 seconds) Admittedly such loops should be tight enough that debugging statements inside the inner loop are generally unnecessary, but perhaps not always. But unlike RR, who suggests some elaborate interpreter-wide, ambiguous ignore-rule to squash out all of these functions, I'm simply suggesting that sometimes it's worth commenting-out debug print calls instead of 'just leaving them there because you won't notice the cost' :). > The easiest way to eliminate these 'dead' calls is to simply comment-out > the > > print call, but I would be quite upset if the interpreter tried to > outsmart > > me and do it automagically as RR seems to be suggesting. > > Indeed, the print function is for general output, not specifically for > debugging. If you have the global print deactivation that RR is > suggesting, then what you have is no longer a print function, but a > misnamed debug function. > Exactly. I was just trying to make the point that it is -occasionally- worth spending the time to comment-out certain debug calls rather than leaving 'dead' function calls in certain places. All the best, Jason -- Jason M. Swails Quantum Theory Project, University of Florida Ph.D. Candidate 352-392-4032
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-03 20:31 +0000 |
| Message-ID | <51acfd28$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #46803 |
On Mon, 03 Jun 2013 15:09:48 -0400, Jason Swails wrote: > But unlike RR, who suggests some elaborate interpreter-wide, ambiguous > ignore-rule to squash out all of these functions, I'm simply suggesting > that sometimes it's worth commenting-out debug print calls instead of > 'just leaving them there because you won't notice the cost' :). +1 Further to this idea, many command line apps have a "verbose" mode, where they print status messages as the app runs. Some of these include multiple levels, so you can tune just how many messages you get, commonly: - critical messages only - important or critical messages - warnings, important or critical messages - status, warnings, important or critical messages - all of the above, plus debugging messages - all of the above, plus even more debugging messages Since this verbosity level is selectable at runtime, the code itself must include many, many calls to some equivalent to print, enough calls to print to cover the most verbose case, even though most of the time most such calls just return without printing. This is a feature. And like all features, it has a cost. If (generic) your application does not benefit from verbose print statements scattered all throughout it, *don't put them in*. But if it will, then there is a certain amount of overhead to this feature. Deal with it, either by accepting the cost, or by writing more code that trades off complexity for efficiency. It's 2013, not 1975, and computers have more than 32K of RAM and the slowest CPU on the market is a million times faster than the ones that took us to the moon, and quite frankly I have no sympathy for the view that CPU cycles are so precious that we mustn't waste them. If that were the case, Python is the wrong language. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-04 06:44 +1000 |
| Message-ID | <mailman.2606.1370292689.3114.python-list@python.org> |
| In reply to | #46808 |
On Tue, Jun 4, 2013 at 6:31 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > ... quite frankly I have no sympathy for > the view that CPU cycles are so precious that we mustn't waste them. If > that were the case, Python is the wrong language. CPU cycles *are* valuable still, though. The efficiency of your code determines how well it scales - but we have to be talking 100tps vs 1000tps here. There needs to be a huge difference for it to be at all significant. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jason Swails <jason.swails@gmail.com> |
|---|---|
| Date | 2013-06-03 15:10 -0400 |
| Message-ID | <mailman.2604.1370286662.3114.python-list@python.org> |
| In reply to | #46708 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote: > On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails <jason.swails@gmail.com> > wrote: > > I'm actually with RR in terms of eliminating the overhead involved with > > 'dead' function calls, since there are instances when optimizing in > Python > > is desirable. I actually recently adjusted one of my own scripts to > > eliminate branching and improve data layout to achieve a 1000-fold > > improvement in efficiency (~45 minutes to 0.42 s. for one example) --- > all > > in pure Python. The first approach was unacceptable, the second is fine. > > For comparison, if I add a 'deactivated' debugprint call into the inner > loop > > (executed 243K times in this particular test), then the time of the > > double-loop step that I optimized takes 0.73 seconds (nearly doubling the > > duration of the whole step). > > It seems to me that your problem here wasn't that the time needed for > the deactivated debugprint was too great. Your problem was that a > debugprint that executes 243K times in 0.73 seconds is going to > generate far too much output to be useful, and it had no business > being there in the first place. *Reasonably* placed debugprints are > generally not going to be a significant time-sink for the application > when disabled. Well in 'debug' mode I wouldn't use an example that executed the loop 200K times -- I'd find one that executed a manageable couple dozen, maybe. When 'disabled,' the print statement won't do anything except consume clock cycles and potentially displace useful cache (the latter being the more harmful, since most applications are bound by the memory bus). It's better to eliminate this dead call when you're not in 'debugging' mode. Admittedly such loops should be tight enough that debugging statements inside the inner loop are generally unnecessary, but perhaps not always. But unlike RR, who suggests some elaborate interpreter-wide, ambiguous ignore-rule to squash out all of these functions, I'm simply suggesting that sometimes it's worth commenting-out debug print calls instead of 'just leaving them there because you won't notice the cost' :). > The easiest way to eliminate these 'dead' calls is to simply comment-out > the > > print call, but I would be quite upset if the interpreter tried to > outsmart > > me and do it automagically as RR seems to be suggesting. > > Indeed, the print function is for general output, not specifically for > debugging. If you have the global print deactivation that RR is > suggesting, then what you have is no longer a print function, but a > misnamed debug function. > Exactly. I was just trying to make the point that it is -occasionally- worth spending the time to comment-out certain debug calls rather than leaving 'dead' function calls in certain places. All the best, Jason
[toc] | [prev] | [next] | [standalone]
| From | Jason Swails <jason.swails@gmail.com> |
|---|---|
| Date | 2013-06-03 15:11 -0400 |
| Message-ID | <mailman.2605.1370286712.3114.python-list@python.org> |
| In reply to | #46708 |
[Multipart message — attachments visible in raw view] — view raw
ack, sorry for the double-post.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.python
csiph-web