Okay, I don't really care if HTML gets slowed down by 10%.  There are
probably really big speedups if you give up on generating a full parse
tree, and instead just deal with the raw tokens.  However, I'd rather
have it the way it is, than to have it a mere 2-4 times faster -- the
parse trees are nice!  Furthermore, there are much more useful things to
go after in Scamper right now.  Tables for one.  Another would be
sharing images that are identical on a page, instead of downloading them
multiple times.  A cache would be very nice, too, but I don't think you
can do it properly without knowing what timezone you are in.  Maybe even
a bogus cache would be nice, though; the expiration could be fixed up
later, I suppose.

That aside, I can't resist geeking out on why things are fast or not
fast.  :)



> > This case happens a LOT for formatting HTML.  Every link,
> > bold, italics, indentation, and font-size change all start a new set
> > of text attributes.
> 
> True, but usually they stay constant for quite a bit. In your example, we
> have 5k text with 212 different runs which makes for an average of 26
> characters per run. This should actually be enough to show some improvement.

Yes, but note that a lot of these characters are added in clumps via
#addString:, which in turn uses repeatLast:times:.


> It didn't. But my timings still differ. What hardware/OS did you run this
> on?! Did you try it with the latest changes to AttributedTextStream as
> well?!

No, the date on AttributedTextStream>>nextPutAll: is 1998!  But,
certainly this is a good place to look to speed up HTML formatting.  It
doesn't have to use class RunArray....

Let's see.  This machine is an Athlon/1.3Ghz.  It has DDR RAM, and it
has, uh, 256k of memory cache on-chip if I'm not mistaken.  That might
just be relevant....


-Lex