Alex Vandiver
2008-10-30 19:39:16 UTC
Heya,
As some of you may know, Jifty uses both HTML::Mason and
Template::Declare as templating systems. Unfortunately, they both have
differing buffer stacks, which means that intercalling between the two
of them is difficult and error-prone. By factoring out Mason's buffer
stack code, they can be made able to intercall, more or less seamlessly.
It does, however, introduce a new dependency on the new
String::BufferStack.
Additionally, this resolves several outstanding bugs with flushing
buffers, filters, and clearing buffers -- specifically, [cpan.org
#38924], and [cpan.org #23535], as well as another related bug using
scomp which I have not reported to bugs.cpan.org yet.
These changes come at a slight performance hit -- 7.46 CPU-seconds
versus 7.39 CPU-seconds over the course of the test suite[1]. I believe
this performance hit comes mostly from the use of method calls, which
are relatively slow in perl. I briefly experimented with reimplementing
String::BufferStack in XS, but this proved to have no measurable
performance improvement, and provided an obviously increased maintenance
hassle.
The only part of the refactoring which whas me uneasy is the use of
the buffer stack to store information about the Mason component stack.
In the interest of keeping code more similar, I left the two intertwined
-- however, this makes relatively little sense if the purpose of the
module is to increase interoperability between templating systems, as
other templating systems will not be able to use the data stack, and
will make no sense of Mason's use of it.
The patch against SVN trunk is attached; code for String::BufferStack
can be found in Best Practical's SVN repository at
http://code.bestpractical.com/bps-public/String-BufferStack/
Comments, thoughts, and feedback?
- Alex
[1] Averaged over the course of 10 test runs each; std. dev. on those
was 0.01563 and 0.03035, respectively.
As some of you may know, Jifty uses both HTML::Mason and
Template::Declare as templating systems. Unfortunately, they both have
differing buffer stacks, which means that intercalling between the two
of them is difficult and error-prone. By factoring out Mason's buffer
stack code, they can be made able to intercall, more or less seamlessly.
It does, however, introduce a new dependency on the new
String::BufferStack.
Additionally, this resolves several outstanding bugs with flushing
buffers, filters, and clearing buffers -- specifically, [cpan.org
#38924], and [cpan.org #23535], as well as another related bug using
scomp which I have not reported to bugs.cpan.org yet.
These changes come at a slight performance hit -- 7.46 CPU-seconds
versus 7.39 CPU-seconds over the course of the test suite[1]. I believe
this performance hit comes mostly from the use of method calls, which
are relatively slow in perl. I briefly experimented with reimplementing
String::BufferStack in XS, but this proved to have no measurable
performance improvement, and provided an obviously increased maintenance
hassle.
The only part of the refactoring which whas me uneasy is the use of
the buffer stack to store information about the Mason component stack.
In the interest of keeping code more similar, I left the two intertwined
-- however, this makes relatively little sense if the purpose of the
module is to increase interoperability between templating systems, as
other templating systems will not be able to use the data stack, and
will make no sense of Mason's use of it.
The patch against SVN trunk is attached; code for String::BufferStack
can be found in Best Practical's SVN repository at
http://code.bestpractical.com/bps-public/String-BufferStack/
Comments, thoughts, and feedback?
- Alex
[1] Averaged over the course of 10 test runs each; std. dev. on those
was 0.01563 and 0.03035, respectively.