Idiom for running compiled python scripts?

[Dennis Lee Bieber]

As of 2005, the world's fastest typist Barbara Blackburn has been clocked
at a peak of 212 words per minute for short bursts. Assuming an average of
five key strokes per word (including the space) that's about 18 key

Did they change the standard? I seem to recall typing tests based on
five letters /and/ a space <G>

I used to manage shorthand at 100 wpm, but could only do the
transcription itself at about 30-35 wpm -- on an electric typewriter;
not a computer with delete keys...
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Mark]

Because this is entirely a trivial saving. Who cares? Sheesh.
...
Saving 18ms on a script that takes 50ms to execute *might* be
worthwhile, ...

I don't understand your attitude. Sure, we are talking slight savings in
machine efficiency but I am sure the python developers have laboured
many long hours on subtle optimisations of the virtual machine, many of
which probably dwarf the issue discussed here. Tell them their work is
trivial and unnecessary. Every little bit helps. Why do I concern myself
with this inefficiency - because it is there.

Of course I realise the modern mantra that "premature optimisation is
the root of all evil" but I don't subscribe to it. Programmers have been
"encouraged" to not give a toss about efficiency and the outcome is all
too apparent - most software today looks and runs like a pile of crap.

 

[irstas]

Not quite irstas BTW ..

I was expecting this, hence the quotes around 'works' .
Another known issue is that globals() dictionary is somewhat
different when ran with my module. You should probably
look into the runpy's source code for better environment
compability (Python25/Lib/runpy.py). Although no quarantees
that it'd help.

Something about the environment is not quite the same. Any ideas?

What Gabriel said may be the correct fix (I actually couldn't
reproduce the
bug so I couldn't test), but here's another idea: You could wrap
your main method in a try-finally block:

def main():
try:
do things
finally:
remove temp files

The finally-block will be executed even if you call sys.exit
inside the try-block. This change will also make it possible
to invoke your script many times, with temp files getting deleted
after each invocation, should this ever be useful to you.
(well, not if you use sys.exit )

 

[Paul Rudin]

Of course I realise the modern mantra that "premature optimisation is
the root of all evil" but I don't subscribe to it. Programmers have been
"encouraged" to not give a toss about efficiency and the outcome is all
too apparent - most software today looks and runs like a pile of crap.

Many people write code that is very obviously "wrong". But that
doesn't mean that labouring for hours over minor speed-ups is actually
worthwile for people who don't, as a rule, do gratuitously "wrong"
stuff in the first place.


There is, of course, a trade-off between programmer time and run
time. It's hard to know where the correct balance lies for each
particular program.

 

[Steven D'Aprano]

I don't understand your attitude. Sure, we are talking slight savings in
machine efficiency but I am sure the python developers have laboured
many long hours on subtle optimisations of the virtual machine, many of
which probably dwarf the issue discussed here. Tell them their work is
trivial and unnecessary.

Why would I do that?

As you said yourself, their optimizations dwarf the trivial issue you
discuss. They, unlike you, grasp that the aim of optimization is to make
significant savings in meaningful places, not waste time making
insignificant savings in meaningless places.

Every little bit helps.

No it doesn't. Spending hours of effort to save 18 seconds a day is a
waste of both time and effort.

If you have a process that takes eight hours and 18 seconds to run, and
you need it to run in eight hours or less, then that 18 seconds is
absolutely critical. But how likely is that? Chances are nobody will care
if the process takes eight hours and ten minutes or seven minutes and
fifty minutes. Saving 18ms once at startup for a single script, or 18
seconds over the course of an entire day, pales into insignificance.

Why do I concern myself
with this inefficiency - because it is there.

Fine fine -- except the hours you spend solving it is an inefficiency a
million times bigger than the one you are concerned with.

Okay, that's not fair -- it might take you hours to solve it once, but
from that moment on, you can save 18ms every time you run a script. In the
course of a day, you might save 18 seconds. In just 600 working days,
you'll have made that time back, and every 18ms after that is pure gain!

BFD.

Except, of course, that each time you type that one extra character, you
lose 160ms to gain 18ms. You're actually going backwards.

And that's the thing that demonstrates that for all your talk of
efficiency, you're not really interested in efficiency. If you were, you'd
do the maths and, having discovered that it costs you 160ms to save 18ms,
you're actually *less* efficient.

Of course I realise the modern mantra that "premature optimisation is
the root of all evil" but I don't subscribe to it.

That's nice.

Programmers have been
"encouraged" to not give a toss about efficiency

Blathering on about saving 18ms might make you feel good, but that's not
efficient. Making the code run 18ms faster at the expense of the total
process running 140ms slower is a pessimation, not an optimization.

 

[Sherm Pendley]

Of course I realise the modern mantra that "premature optimisation is
the root of all evil" but I don't subscribe to it.

Note the first word - premature. It's an important distinction, and you've
entirely missed it.

Optimization is premature if you haven't yet ensured that your program is
correct. Worry about getting it right first - and that includes selecting
the appropriate algorithms.

Optimization is premature if you haven't yet profiled your code to identify
precisely *what* code is a bottleneck.

Once you've identified your code's bottleneck(s), and verified that your
algorithm(s) is (are) ideal - then it's time to optimize the implementation
of the algorithm(s), if you still need to. (Most of the time you won't; in
my experience, bottlenecks are the result of badly-chosen algorithms in at
least nine out of ten cases.)

Programmers have been
"encouraged" to not give a toss about efficiency

Nonsense. Efficiency is about making the best use of limited resources, and
in most cases the most limited resource is people. Saving $x in hardware
cost by spending $x*10 on programmer salary is not efficient.

and the outcome is all
too apparent - most software today looks and runs like a pile of crap.

Most software today is written by comparitive amateurs who use "clever" code
that tries to compensate for badly-chosen algorithms, who guess at where
bottlenecks "might" be instead of profiling their code to see exactly where
they *are*, and who scoff at Knuth's "mantra" because they've misunderstood
what he meant by both "premature" and "optimization".

In other words, premature optimization is quite often the reason why software
often looks and runs like a pile of crap.

sherm--