[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How expensive is building canonical strings?
> 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);
t = scanner->get_token(); // eat extra period at end of expr
if (t->type != '.') scanner->push_token(t);