Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by barries (2159) on 2003.01.13 13:47 (#15972)
    XML::Filter::Dispatcher is definitely slower than TWIG. It's still young and it will probably never be as optimized as TWIG is for TWIG's purpose.

    That being said, you may want to look at the struct() and hash() extension functions that return Perl data structures something like TWIGs. <plug>My shiny, tiny new BFD [cpan.org] module might help you see them:

       'foo' => [ 'hash()' => sub { use BFD; d xvalue } ],

    ;)</plug>.

    Along with optmization, I'd like to enable X::F::D to generate single-purpose handler or filter classes from rulelists and, optionally, save them to .pm files. In other words, you should be able to ask X::F::D to generate MyTwigger.pm (or MyFooFilter.pm, say). This would be a complete SAX handler (or filter) class that would run lots faster than the interpreter in XML::Filter::Dispatcher.

    X::F::D isn't meant to compete with TWIG, it's meant to allow for more intricate SAXual relations between XML and Perl than TWIG is. So it's likely that TWIG will always be faster than X::F::D if you're doing purly TWIGy things. I'm using it when (a) programmer convenience matters more (which is often) and/or (b) when TWIG doesn't do what I want (which is also often, because I'm picky). YMMV.

    Once X::F::D is more stable (it's still beta, having only recently graduated from alpha in my mind), I anticipate some significant optimizations, especially in cases where its processing lots of rules. And even more performance should be possible when it allows you to generate those one-off classes and Perl modules from rule lists.

    The generation of Perl modules (as opposed to just generating classes in memory) will mean specifying actions as strings instead of CODE refs ("foo()" instead of "sub { foo() }"). Those should rock.

    - Barrie