From:  Dean Swan at MITEL on 04/25/2000 02:33 PM

>Progremmers' intutions about performance seem to be a lot worse than
>they expect.

     While this is a subjective observation, I'm inclined to agree.  Especially
in Smalltalk, where you're working so far away from the hardware.  My usual work
is embedded DSP firmware, where my applications are so demanding that I'm still
counting clock cycles when I've got 300 MIPS available (spread across four
processors), as in my current project at work.

>  I'm no different here.  But even though this performance
>argument is intuitively correct, it also stands true that my version
>with the extra message sends was approximately as fast, at least after
>I put in BitBlt sends in fieldAt:width:put:.

     True.  The difference is probably quite small for each iteration,
especially for lower order problems (i.e. few, small fields per chromosome).

>  A good strategy is probably to
>start with easily readable code, and then implement optimizations one by one,
>testing as you go, to see what is making a difference and by how much.

     Good advice, no doubt, but often difficult to follow since it can be a time
consuming and/or tedious approach.

     Perhaps this is a zero-sum phenomenon.  You can produce iterations of an
implementation in Smalltalk faster, so trying multiple approaches is more
reasonable than when implementing in C or assembly, where the iteration time for
the devlopment cycle is longer.


>By the way, another angle you might try for performance is to use an
>array of integers for the chromosomes.  That way, extracting and swapping
chromosomes
>chromosomes becomes very cheap.  Furthermore, operations between
>chromosomes should still be pretty fast.

     This is, indeed, worth trying.  If/when I get around to it, I'll post a
comparison of the implementations.

                                         -Dean
                                         dean_swan at mitel.com