Re: [Xen-devel] [PATCH 09 of 10] xenalyze: add a basic plugin infrastructure

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Jun 7, 2012 at 4:26 PM, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> On 07/06/12 12:05, George Dunlap wrote:
>> On 31/05/12 12:16, David Vrabel wrote:
>>> Allow xenalyze to be include (at build time) plugins that can do
>>> per-record actions and a summary.  These plugins can be in C or C++.
>>>
>>> The plugins entry points are in struct plugin and pointers to all the
>>> plugins linked in xenalyze are placed in a "plugin" section so
>>> plugin_init() can find them all.
>>>
>>> A new command line option (-p, --plugin=PLUGIN) is added to enable one
>>> or more plugins.
>>>
>>> A sample plugin (skeleton) is included (mostly because at least one
>>> plugin must be present for the build to work).
>>>
>>> Signed-off-by: David Vrabel<david.vrabel@xxxxxxxxxx>
>> So what's the main motivation of having this plugin infrastructure?  The
>> one plugin example you have ("batch-size", patch 10) seems simple enough
>> that it should be fairly straightforward to just add as an option, with
>> not much more boilerplate than C++ already requires.
>>
>> Looks like potential advantages may include:
>> * Ability to use C++ language (for those who care for such things)
>> * Ability to use STL for complex data structures
>> * Ability to add an option like the "batch-size" plugin in a concise,
>> self-contained way
>
> These are the main reasons.  The last is the most important.
>
>> Potential disadvantages include:
>> * An extra O(N) loop on the hot path (where N = # of enabled plugins)
>> * For each enabled plugin, an extra full function call on the hot path;
>> and a C++ function at that, which (my prejudice tells me) is likely to
>> be more wasteful time and space-wise than a C function.
>
> I'd be surprised if these had any practical performance penalty but I'll
> collect some measurements.

Thanks.  I was going to mention but forgot: about 6 months ago I did a
week's worth of work optimizing xenalyze.  At the beginning of the
week, it was taking almost 2 minutes to do a "summary" analysis on a
700MiB file; after my optimizations, it took 10s.  In that case things
as simple as doing an extraneous integer division per record had a
measurable impact.  So I'm not just being paranoid.  Going from "I can
wait 10s for this to complete" to "I'm going to switch to a different
task" can have a pretty big impact on my working effectiveness, at
least. :-)

I also have a set of patches that speed up "xenalyze -a", but that's a
lot more tricky and invasive, as with a 700MiB file you're actually
generating and writing to disk more than 1GiB of data.  The solution
there is mainly to use bespoke printing routines, rather than the libc
ones.  Using a plugin infrastructure and going to more indirection /
abstraction seems like it would be going in the opposite direction.
:-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel