Plugin project proposal
Nicolas.Williams at oracle.com
Fri Jul 16 16:24:18 EDT 2010
On Fri, Jul 16, 2010 at 03:56:17PM -0400, Zhanna Tsitkova wrote:
> > 3. The type-safety of plugin interfaces is important. However it
> > comes with the price of making code less readable and, perhaps,
> > negatively effects the performance.
> Meant to say in line with the discussion: However implementing it
> using hash table approach comes with the price of making code less
> readable and, perhaps, negatively effects the performance.
I wouldn't worry too much about the performance of looking up a symbol.
First of all, there's more macro cleverness we can do to speed up the
#define GET_PLUG_FUNC(...) \
(func_var) = \
(plug_type ## _vtable[GET_PLUG(STRINGOF(plug_name))].fname != \
NULL) ? (plug_type ## _vtable[GET_PLUG(STRINGOF(plug_name))].fname \
Second, we're talking about code that talks to remote services (DNS
servers, KDCs, OCSP responders, CRL distribution points, kadmin servers,
etcetera) and does relatively expensive cryptographic operations. A
lookup by string in a small table will be in the noise.
Let's worry about performance where it matters, and let's get numbers
rather than stab in the dark. But also, let's characterize algorithms
properly -- something we can do without measuring performance. Table
lookups by name need not be worse than logarithmic with element count
(though likely linear for small numbers of elements). The cost of all
plugins at once is clearly linear with respect to plugin count (assuming
uniform load + init time). The former is clearly bounded, the latter
cannot be be (if loading includes initialization).
IMO the above is a very strong indication of where we should optimize:
we should avoid first of all unbounded tasks whose costs grow linearly.
Years of collective Linker/loader experience bears this out too, IMO.
We're talking about duplicating a small part of what the rtld does,
after all. We know that symbol table lookups get slow with large symbol
tables, but are not that noticeable with small symbol tables. We also
know that lazy loading is an important rtld feature, and for good
The above argument squares my non-concern over the performance of plugin
function lookup by name string with my concern over loading all plugins
at context init time.
More information about the krbdev