On 03/14/2010 02:50 PM, Darryl Green wrote:
On Sun, 2010-03-14 at 14:21 +0300, Andrey Semashev wrote:
But short circuiting the core is not doable without considerable changes in the core, log record and, probably, the logger. Also, this would make the loggers tied to the sinks, which may be just fine for your case, but not for Boost.Log in general.
I'm not quite following what coupling you are concerned about. Our existing logger has a shared ptr to a (maintained by the filtering logic) container of shared ptrs to sinks which seems harmless enough?
My understanding was that your loggers had a set of pointers to sinks, which does not change, unless the configuration is updated (which was the reason of higher performance). This is the coupling I was talking about - a logger is bound to the fixed set of sinks, and in no way it can emit a record that would pass to a sink outside of this set. If my understanding is not correct, and the set of sinks is dynamically composed during filtering, then it doesn't differ from what Boost.Log currently does.
Even if the attribute value isn't literally a container of pointers to sinks, it would surely be possible to have an attribute value identifying (with help from a sink front end filter that checked the attribute) which sinks the logger fast filter had selected?
I think, you've missed an important thought before this, which makes me hard to understand what you meant here. Again, if your setup is static, in the sense I described earlier, you can cache the set of sinks which consumed the particular record (since you can always be sure that the set will always be the same). However, that won't speed things up, since even if you pass that cached information to the filter with the next record, it will have to find its sink in it, hence you will still have a lookup. And since your setup is not static in the first place, all these caching dances are moot anyway.