On some profiles of Andrea's from #11332, I found that a great deal
of time can still be attributed to functions called from
update_router_have_minimum_dir_info(). This is making our
digestmap, tor_memeq, and siphash functions take a much bigger
portion of runtime than they really should.
If we're calling update_router_have_minimum_dir_info() too often,
that's because we're calling router_dir_info_changed() too often.
And it looks like most of the callers of router_dir_info_changed()
are coming as tail-calls from router_set_status() as invoked by
channel_do_open_actions().
But we don't need to call router_dir_info_changed() so much! (I'm
not quite sure we need to call it from here at all, but...) Surely
we don't need to call it from router_set_status when the router's
status has not actually changed.
This patch makes us call router_dir_info_changed() from
router_set_status only when we are changing the router's status.
Fix for bug 12170. This is leftover from our fix back in
273ee3e81
in 0.1.2.1-alpha, where we started caching the value of
update_router_have_minimum_dir_info().
--- /dev/null
+ o Major bugfixes (performance):
+ - Do not recompute whether we have sufficient information to build
+ circuits every time we make a successful connection. Previously,
+ we would forget our cached value for this flag every time we
+ successfully opened a channel (or marked a router as running or not
+ running for any
+ other reason), regardless of whether we had
+ previously believed the router to be running. This forced us to
+ run a fairly expensive update operation with relatively
+ high frequency.
+ Fixes bug 12170; bugfix on 0.1.2.1-alpha.
if (!up && node_is_me(node) && !net_is_disabled())
log_warn(LD_NET, "We just marked ourself as down. Are your external "
"addresses reachable?");
+
+ if (bool_neq(node->is_running, up))
+ router_dir_info_changed();
+
node->is_running = up;
}
-
- router_dir_info_changed();
}
/** True iff, the last time we checked whether we had enough directory info