[Etoys] Performance improvements form 3.9 (backported) #3

[Yoshiki Ohshima]

  Marcus,

> >   This one was considered "it seems to be ok.  We don't find any code
> > that changes the result".  I don't remember the further discussion,
> > but was there some analysis, or it is just seems to be ok as it is
> > long time in 3.9 line images?
> 
> It's in 3.9 for some time now, yes. But it should not be really  
> perfomance
> critical, so you might not want to add it.

  It does make difference, though.  I like it in the image.  There
seems to be small small chance that some area breaks, but it should be
something we can fix later.

  #copy to Array, String, etc. nils-out memory redundantly (and send
#postCopy for nothing), and these memory scanning is slow on such
platforms.  I'll experiment that.

> -StrikeFontSet has been optimized to use the bitblt text primitive  
> for bytestrings. For the multibyte path, it was still possible to  
> save a few sends for a noticable improvement.
> "
> 	http://bugs.impara.de/view.php?id=1628
> 	http://bugs.impara.de/view.php?id=1672
> 
> But you worked in that direction, so it might be already in or hard  
> to merge.

  I'll check that.

> Another change that I did not send is the Gradient Cache (Eddie  
> Cottongim)
> http://bugs.impara.de/view.php?id=1759	
> I tested it on the OLPC image, and there are not many gradients left,  
> so it will not
> have any positive effect, I think.

  Ah, we should think about the memory usage too (we generally favor
speed over space), and as you say, we are trying to minimize the use
of gradient, so probably we should wait on this one.

> One changeset you might consider to load is Andreas' version of the  
> ByteSymbol primitive fix:
> http://bugs.impara.de/view.php?id=1382
> 
> You fixed already the hashing primitive call, so this won't have any  
> too big impact, but
> it's nice to have the best solution for that (I think this fix is in  
> 3.8.1, too).

  And, there is a good reason to be in sync somewhat.

  Thanks!

-- Yoshiki