[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Python too slow?

dongie.agnir

1/9/2008 7:12:00 PM

I'm pretty new to Python, and even newer to Image/Video processing,
and trying to get started on a project similar to GRL Vienna's laser
marker. I found some sample code here http://janto.blogspot.com/2006/01/motion-capture-in-p...,
but after running the code with the included sample input file, it
seems quite slow (1-2 seconds from start to finish to do the 800 by
600 gif image).

Is there a better way to do color tracking, or is Python just too slow
as an interpreted language to do any effective color tracking?
65 Answers

Bruno Desthuilliers

1/9/2008 8:26:00 PM

0

dongie.agnir@gmail.com a écrit :
> I'm pretty new to Python, and even newer to Image/Video processing,
> and trying to get started on a project similar to GRL Vienna's laser
> marker. I found some sample code here http://janto.blogspot.com/2006/01/motion-capture-in-p...,
> but after running the code with the included sample input file, it
> seems quite slow (1-2 seconds from start to finish to do the 800 by
> 600 gif image).
>
> Is there a better way to do color tracking,

Not having any experience with this domain, I can't comment on this.

> or is Python just too slow
> as an interpreted language

Being "interpreted" is a quality of an implementation, not of a
language. And the reference implementation of Python (CPython) is not
interpreted, it's compiled to byte-code, which is then executed by a VM
(just like Java). So while CPython may possibly be too slow for your
application (it can indeed be somewhat slow for some tasks), the reasons
are elsewhere (hint: how can a compiler safely optimize anything in a
language so dynamic that even the class of an object can be changed at
runtime ?) ...


> to do any effective color tracking?

dongie.agnir

1/9/2008 8:46:00 PM

0

Thanks for the clarification.

Though I was hoping someone could give me a definitive answer. I was
quite excited about this project initially, but seeing the actual
execute times was a big downer. Seeing that the original laser marker
by GRL Vienna is done in Processing which from what I know is built on
Java, I was hoping that Python would be up to a similar task.

Christian Heimes

1/9/2008 9:16:00 PM

0

dongie.agnir@gmail.com wrote:
> I'm pretty new to Python, and even newer to Image/Video processing,
> and trying to get started on a project similar to GRL Vienna's laser
> marker. I found some sample code here http://janto.blogspot.com/2006/01/motion-capture-in-p...,
> but after running the code with the included sample input file, it
> seems quite slow (1-2 seconds from start to finish to do the 800 by
> 600 gif image).

Have you profiled your application? Do you know the bottle necks and the
reason for the bottle necks? Is your application IO, memory or CPU
bound? Have you considered rewriting the bottle necks in C?

Christian

Ben Finney

1/9/2008 10:54:00 PM

0

Christian Heimes <lists@cheimes.de> writes:

> dongie.agnir@gmail.com wrote:
> > [...] after running the code with the included sample input file,
> > it seems quite slow (1-2 seconds from start to finish to do the
> > 800 by 600 gif image).
>
> Have you profiled your application? Do you know the bottle necks and
> the reason for the bottle necks? Is your application IO, memory or
> CPU bound? Have you considered rewriting the bottle necks in C?

All good questions. Another important one: Is the startup time of the
Python process (i.e. before executing any of the actual statements in
the program) a significant part of the total time in this case?

--
\ "In the long run, the utility of all non-Free software |
`\ approaches zero. All non-Free software is a dead end." â??Mark |
_o__) Pilgrim |
Ben Finney

bruno.desthuilliers@gmail.com

1/9/2008 11:03:00 PM

0

On 9 jan, 21:46, "dongie.ag...@gmail.com" <dongie.ag...@gmail.com>
wrote:
> Thanks for the clarification.
>
> Though I was hoping someone could give me a definitive answer.

Sorry - but I'm definitively not the right person on this...

> I was
> quite excited about this project initially, but seeing the actual
> execute times was a big downer. Seeing that the original laser marker
> by GRL Vienna is done in Processing which from what I know is built on
> Java, I was hoping that Python would be up to a similar task.

Java's declarative static typing allow agressive just-in-time
optimizations - which is not the case in Python due to it's higly
dynamic nature[1]. You may want to have a look at psyco (a JIT
compiler) or to look for other angles (if there's any - IIRC the
example you're talking about already uses at least PIL for image
processing and something like scipy or numpy for intensive math ops).

If none of the two above answers fits your needs, and no Python Guru
comes with a better answer, then I'm afraid you'll have to go for a
language with a faster implementation. Python is quite faster nowadays
than it used to be, and is usually fast enough for most day-to-day
programming tasks (a, but it's still not as highly optimized as some
Lisp implementations (to compare to another highly





[1] you can read more on this on the pypy website, and specially here
IIRC: http://codespeak.net/pypy/dist/pypy/doc/dynamic-language-transl...)

bruno.desthuilliers@gmail.com

1/9/2008 11:11:00 PM

0

On 10 jan, 00:02, "bruno.desthuilli...@gmail.com" >

(sorry, hit the wrong key - time to bed I guess...)

> If none of the two above answers fits your needs, and no Python Guru
> comes with a better answer, then I'm afraid you'll have to go for a
> language with a faster implementation. Python is quite faster nowadays
> than it used to be, and is usually fast enough for most day-to-day
> programming tasks (a

.... at least for my own day-to-day tasks)

> but it's still not as highly optimized as some
> Lisp implementations (to compare to another highly

.... dynamic language).

<done>

dongie.agnir

1/9/2008 11:46:00 PM

0

Okay I profiled the code and here is the output:

http://heightened.files.wordpress.com/2008/01/...

It seems that the function it spends the longest on is the red_points
function that he uses to find the points.



Mike Meyer

1/10/2008 12:09:00 AM

0

On Wed, 9 Jan 2008 15:45:41 -0800 (PST) "dongie.agnir@gmail.com" <dongie.agnir@gmail.com> wrote:

> Okay I profiled the code and here is the output:
>
> http://heightened.files.wordpress.com/2008/01/...
>
> It seems that the function it spends the longest on is the red_points
> function that he uses to find the points.

Ok, so what's that look like?

Python - used properly - can be quite fast. We process 1.5 billion
rows a day through our python-based ETL system. The trick is to arrange
things so that the cpu-intensive work gets done by C code. Preferably
by tightly coded C written by very sharp people and extensively
tweaked to make it go fast. In our case, the T part of our ETL system
is handled by a custom C library that's been around - and being
debugged and tweaked - for quite some time. Other examples include
much of the code for python's builtins, and things like the Numpy
extension library.

<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/consu...
Independent Network/Unix/Perforce consultant, email for more information.

Ed Jensen

1/10/2008 1:41:00 AM

0

Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> wrote:
> And the reference implementation of Python (CPython) is not
> interpreted, it's compiled to byte-code, which is then executed by a VM
> (just like Java).

Wow, this is pretty misleading.

Java is, indeed, compiled to bytecode; however, modern JVMs typically
compile the bytecode to native code and then execute the native code.

CPython strictly interprets bytecode; it does not compile the
bytecode to native code.

Steven D'Aprano

1/10/2008 2:11:00 AM

0

On Wed, 09 Jan 2008 21:26:05 +0100, Bruno Desthuilliers wrote:

> hint: how can a compiler safely optimize anything in a language so
> dynamic that even the class of an object can be changed at runtime ?

Is that a trick question?

By finding things to optimize that *can't* change at runtime.

E.g. a keyhole optimizer that detects when you write something like this:

def foo():
x = 1 + 2
return x

and optimizes it to this:

>>> import dis
>>> dis.dis(foo)
2 0 LOAD_CONST 3 (3)
3 STORE_FAST 0 (x)

3 6 LOAD_FAST 0 (x)
9 RETURN_VALUE

(Only in CPython version 2.5 or better.)

Okay, okay, so constant folding isn't going to save you a lot of time
(unless your constant is being re-calculated millions of times) but it's
still an optimization. There are others, some have been done (e.g.
optimize away the quadratic behaviour for string concatenation in some
limited cases), some are possible but rejected by the BDFL (e.g. tail-
call optimization), presumably there are some possible but not yet
implemented or even discovered (which is the point of the PyPy project).

You are correct that optimizing Python is hard. However, in many cases,
the problem is not that Python is too slow, but the specific algorithm
chosen by the programmer is slow, e.g. no compiler optimization is going
to turn an O(n**2) algorithm into an O(1) algorithm.

The Original Poster says it takes one or two seconds to process an
800x600 GIF. That sounds believable: on my PC, it takes about five
seconds to loop over range(800*600) and do a tiny bit of processing.
Something like Psycho might speed that up a lot, possibly by an order of
magnitude or two.



--
Steven