[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
How expensive is building canonical strings?
- To: self-interest@otis.Stanford.EDU
- Subject: How expensive is building canonical strings?
- From: MCR@physics.carleton.ca (MICHAEL RICHARDSON)
- Date: Tue, 1 Jun 1993 17:41:48 -0400 (EDT)
- Resent-date: Tue, 1 Jun 93 14:50:15 PDT
- Resent-from: Urs Hoelzle <urs@otis>
- Resent-message-id: <9306012150.AA09391@otis.Stanford.EDU>
- Resent-to: real-self-interest
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. The fastest
way is probably a case statement (which would reduce to pointer comparisons
for canonical strings), with specific method lookups there. I see the
problem with maintenance in this case though.
Alternately, maybe the event could have a `dispatchTo:' method that
does the right thing.
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.
I'm not sure at all how much time is spent doing this, probably not much
compared to actually handling the event, but if you are just discarding that
event anyway...
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.