Python too slow?

[A.T.Hofkamp]

On 2008-01-09, dongie.agnir at gmail.com <dongie.agnir at 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-python.html,
> 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?

People seem quite obsessed with execution speed of CPU's.

I have come to believe that it is only one part of the equation, development
time and ease of maintenance or modification is another one, which I believe is
much more interesting to perform as fast as possible.

1-2 seconds may be slower than some alternative solution (you could in
principle develop custom hardware for it, and do the trick in a few
nano-seconds). The question that arises (for me at least) is, how fast can you
write, maintain, and modify what you want in that other solution.

Suppose you can do color-tracking in 0.5 seconds. So, you gained 1.5
seconds CPU time.
Now the question you need to answer for yourself, is how much more worth is
your own time compared to the gain in CPU time. If you think they are equal (ie
the problem as a whole should be solved as fast as possible, thus the sum of
development time + execution time should be as short as possible), you can
spend an additional 1.5 seconds development in the alternative solution.

Of course, if you do more color-tracking, the differences between alternative
solutions become larger, and your custom hardware solution may become a
feasible alternative.... :)

In my experience however, differences in CPU execution time are usually
meaningless compared to differences in development time.


Albert