On 09/09/2021 21:02, Petr Menšík wrote:
> Hi Dominik and Simon,
>
> I like the idea, but not so much the implementation. This table is
> processed per packet and is quite inefficient. The more types we add to
> it, the more inefficient it becomes. What about transformation to more
> computer friendly version, which does not have to iterate over all
> records one by one.>
> I made optimized version of above and used Dominik's data with some
> regexps to convert it to different format. It is slightly less human
> friendly, but much more machine friendly. I think it scales well.
>
> Logging each query would be slow anyway, but we should not waste CPU
> cycles previous way.
>
> What do you think?
I think this is solving the wrong problem. We don't actually need to
look up the type unless logging is enabled. The output of querystr() is
only ever used as an argument to log_query() and log_query() just
returns of option_bool(OPT_LOG) is not set, but querystr has already
been called anyway by that time.
A cheap and nasty solution is to just return NULL from querystr() when
option_bool(OPT_LOG) is not set, but that will bite someone one day who
uses it for something not long-related.
Much tidier is to simplify things and add an extra parameter to
log_query which is the type, if type is non-zero, log_query calls
querystr(), so
log_query(flags, name, addr, querystr("description", type));
becomes
log_query(flags, name, addr, "description", type);
querystr becomes a local function to cache.c or just gets rolled into
log_query().
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
