It is very advantageous to have mechanism and policy separated
(as mentioned in Bro paper) but does it incur any overhead ?The paper says: for each event passed to the interpreter,
it retrieves the (semi-) compiled code for the corresponding handler,
binds the values of the events to the arguments of the handler, and
interprets the code.Would'nt this take some extra time compared to if it was already compiled?
(although the flexibility is lost in the latter case)
There are two separate issues. One is whether interpreting the policy
script incurs a performance penalty over compiling it. The second is
whether decoupling mechanism from policy (so the fact that the event engine
doesn't know what the handler will do) incurs a performance penalty.
Regarding the first, profiling shows that Bro would certainly run faster
if the script were compiled into a faster-to-execute form. Developing
a compiler is on the Wish List, and I may have a student working on it
at some point in the future; but it's quite involved, and before embarking
on it in earnest, I want to develop better mechanisms for profiling just
where Bro scripts spend most of their time. The student working on all of
this is Umesh Shankar; he's developed an interactive Bro policy script
debugger, which will be included in the next release. Once that's done,
I'm hoping we can extend the framework with profiling hooks, so we can find
out where do various scripts spend their time. It may turn out that the
bottlenecks can be optimized without moving towards full-blown compilation
of policy scripts.
Regarding the second, I don't think the mechanism/policy separation is
all that expensive per se. It entails one layer of binding between the
event engine and the policy scripts, but I don't think that's inherently
expensive, due to the event engine's ability to skip the work associated
with events which the policy script doesn't handle - that's the most
important feedback it needs from the policy script.
Vern