
In order to support legacy perl versions (<5.005_03), libwhisker uses a
few non-optimal workarounds in order to support more platforms.  However,
there are times when it may be beneficial to optimize libwhisker for the
current platform.

In particular, there is an interesting dilemna when it comes to the
4-argument version of the 'substr' function.  Basically, older perl
versions only support the 3-argument version.  This means that, in order
to work with older perl versions, libwhisker has to use two substr() calls
(one to extract the required substring, and one to replace it).  However,
there is a known bug in older perls where substr used as an lvalue (i.e.
assigned to) causes a memory leak.  Given (many) repeated calls, this can
start to become a resource problem.  So another alternative is to use the
unpack() function to extract two strings from a single string.  Safe from
memory leaks, but horribly inefficient.

All these alternatives come with a price, of course.  The non-legacy,
4-argument substr() is the fastest.  The memory leaking double-substr() is
the second fastest.  The safe unpack() version is extremely slow (4 times
slower than the single substr(), twice as slow as the double substr() ).

By default, libwhisker uses the double substr() approach, so that
libwhisker will at least run/function properly on older perl versions, but
not make a huge performance decrease for those running on newer perl.  
Those of you running on newer perl versions and wishing to run faster can
search for 'SPEEDUP' in libs/http.pl and change the code as indicated.  
For those of you who are stuck on old perl versions, and can't afford the
memory leak, then search for 'MEMLEAK' in libs/http.pl and change the code
as indicated.  For both SPEEDUP and MEMLEAK, there are two locations to
fix in http.pl.  If you want to revert back to default, search for
'LEGACY'.

What's the actual performance gain?  Well, realisticly, it's not much.  
Figure a 1000 average web requests will result in approx 8000-10000 calls
to the target code--we're talking 1-4 additional seconds at most on decent
(300Mhz+) systems.  My off-the-cuff benchmarks on my Pentium 200MMX Linux
system using Benchmark.pm via perl 5.005_03 are:

-- 100,000 iterations --
single 4-arg substr:	3  seconds
double substr:		7  seconds
unpack:			16 seconds

To reach that many iterations libwhisker will need to do over 10,000 web
requests--and odds are the network latency will be greater than the 4
second gain from switching from a double substr to the single 4-arg
version.

So, maybe nothing to really worry about (except if you want to ensure no
mem leaks and switch to the unpack() version); I figured I would at least
give people the option of switching, if they really wanted to. :)
