Re: [pygame] pygame slowness

[Knapp <magick.crow@xxxxxxxxx>]

Yes, it seems we do agree. I think the problem is that there are two
(or more) kinds of optimization. There are code tweaks like unrolling
loops and doing everything in line that leads to very fast and
terrible code and then there is optimization that comes from doing
things the correct way.

I was thinking about the bubble sort vs the quick sort but the problem
there is that the bubble sort is really much easier to read so I think
this is an example of type one and type two code together.

I think a good example of python code that is faster and easier to
read is the distance calculation.

d=hypot( dx, dy)

VS

d=sqrt( dx**2 + dy**2)

The first is simple to read and fast. The next is slow and confusing.
Often my problems with slow code is using the second method * 100,
then taking that and making it the key worker of my inside loop!

Love your title!

> I believe you're in vehement agreement with me.  :-) I believe in writing
> good, clear and maintainable correct code first, and then improving it for
> performance reasons second.  Worrying too much about efficiency and speed
> before you have code that actually does what you need it to is premature
> optimization.  Sometimes, of course, I don't live up to my own beliefs,
> but it's because I'm a weak and imperfect human being. :-)
>
> It's been my experience that too often we make bad guesses ahead of time
> as to what actually needs to be optimized.  To that end, you're better off
> having a clear, maintainable code base that does what it ought to rather
> than having a brittle mess that performs wonderfully but scares you
> everytime you want to add a new feature.  Obviously, the ideal is to apply
> best engineering practises at every step, but it's easy for even the best
> engineers to sometimes not see the forest because all these darn trees
> keep getting in the way.
>
> I'm not advocating "just drop in random or bubble sort now and if it's a
> problem do quicksort later" things.  If you know the cleanest, fastest way
> to implement something, then naturally that's the way to do it.  But when
> you're in the thick of something where the ultimate algorithm is unclear,
> I come down on the side of "make the code readable, well-documented and
> correct first, then go back and optimize only if it becomes a problem."
>
> --
> Randy Kaelber                                        randy@xxxxxxxxxxxx
> Scientific Software Engineer
> Mars Space Flight Facility, Department of Geological Sciences
> Arizona State University, Tempe, Arizona, USA
>