On May 16, 12:24 pm, "inhahe" <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote in messagenews:[EMAIL PROTECTED] > > > > > 2. Once the code is functioning, benchmark it and find the > > bottlenecks. Replace the problem methods with a C extension. Refactor > > (and check your unit tests again) if needed to break out the problem > > areas into as small a piece as possible. > > There's probably only 2 or 3 basic algorithms that will need to have all > that speed. > > > > > 3. If it is still slow, embed some assembler where it is slowing down. > > I won't know if the assembler is faster until I embed it, and if I'm going > to do that I might as well use it.
You won't know if the C is faster than the assembly until you write it, and if you're going to do that you might as well use it... If the C is fast enough, there's no point in wasting time writing the assembly. (Also FWIW C and C++ are different languages; you seem to conflate the two a few times upthread). -- http://mail.python.org/mailman/listinfo/python-list
