How expensive is building canonical strings?

[Urs Hoelzle]

>   In eventWater dispatch, it uses sendTo: With:
>   The receiving is a string built up by putting a ':' at the end of the
> event name.
> [...]
>   I'm wondering how expensive this type of run-time look up is. 
>   It just seems to me that building a string, and making it canonical 
> (which presumably involves searching through the equivalent of the 
> `atom table') could be quite an expensive thing to happen for every event.

It's probably not blindingly fast but fast enough to handle a few
thousands of events per seconds.  If the selector is relatively
constant (i.e. you're performing 'foo:' several times in a row) the
perform is actually very fast.  So the answer is "yes it's probably
slow but it hasn't ever been a problem for us so far".  (In any case,
the _Perform is probably slower than the canonicalization.)

But you point to a real problem: in 2.0.1 it's hard to tell where the
time goes since there are no real profiling tools.  However, we've
made good progress on this issue - our current system has a
source-level profiler that could tell you exactly how much time you
spent in the string canonicalization or in the concatenation.

> p.s. while I've got your attention: putting '.' at the end of statements
> in a _RunScript'ed file doesn't work. This is really annoying when converting
> code from simple statements into a method. Someone said this might be fixed
> in 2.0 when I mentioned it in 1.1, but nothing has changed. If someone wants to
> point me towards the appropriate C parser files I'd appreciate it. I think that
> Parser::testDone has to be willing to eat '.' tokens while looking for ACCEPT,
> but I'm far from certain from a cursory glance at the code.

Yes, we forgot to fix this in 2.0.1, sorry about that.  The right
place to fix it would be readExpr() in parser.c.  After the line

      e = parser.parseExpr(t, true);

insert

      t = scanner->get_token();	    // eat extra period at end of expr
      if (t->type != '.') scanner->push_token(t);

-Urs