Dean_Swan at Mitel.COM wrote:
>      I'm not to sure this is a good idea.  Certainly, this is conceptually
> cleaner, but gets and sets ultimately end up sending fieldAt:width: and
> fieldAt:width:put:, which end up doing a lot more than three BitBlts, even if
> the puts are optimized in the same way that the gets are. 

Four, instead of three.


> It also involves more
> message sends, which are a major bottleneck for Squeak, because even my fastest
> Mac (my wife's iMac G3/333), and my fastest PC (PII/450) only crank a little
> over a million sends/second. 

Progremmers' intutions about performance seem to be a lot worse than
they expect.  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:.  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.


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.



> >Changing the block to a method didn't seem to hurt things, and
> >the non-local features of blocks turned out not to be needed.
> 
>      Keep in mind that the class comment demonstrates an absolutely trivial
> application.  My real application does involve some other non-local references
> to objects that represent the search target, and they are *very* expensive to
> compute, so they would have to be made visible to the evaluator method by some
> means (class pools? - ick) because recomputing them for every reference is just
> out of the question.  I still haven't found very good answers for my target
> problem, and I've let this thing crank for days on my fastest machines.
> 

Does the evaluation function change from one iteration to the next?  If
not, then you can give the evaluator some instance variables pointing to
the relevant data.  I would imagine that once the GA gets started, the
evaluation function is usually held constant until you actually find a
good solution....


Anyway, I'm not saying blocks should be removed.  But I *am* suggesting
that most blocks are used either for simple functions [ :x :y | x + y ],
or for control structures.  Outside of control structures, simpler
blocks which cannot, eg, assign back to local variables, are sufficient.
 Of course, blocks are used heavily in Smalltalk for control structures,
so that means blocks aren't going to get any weaker in the near
future.....


-Lex