Yes, Embperl per default caches a compiled version of the
stylsheet in
memory.
Gerald
P.S. There are also options to cache the result of the xslt
transformation
or any itermediate steps
Oh - A way of making it even faster in the benchmarks?
Yes, that should be possible. I
This differs from Embperl where the application layer itself handles
the XSLT rending, not the script/XML file:
PerlSetEnv EMBPERL_RECIPE LibXSLT
PerlSetEnv EMBPERL_XSLTPROC libxslt
PerlSetEnv EMBPERL_XSLTSTYLESHEET $ROOT/hello.xsl
So perhaps Embperl 2 is able to do some
From: Gerald Richter [mailto:[EMAIL PROTECTED]
Yes, Embperl per default caches a compiled version of the
stylsheet in
memory.
Gerald
P.S. There are also options to cache the result of the xslt
transformation
or any itermediate steps
Oh - A way of making it even faster in the
Ask Bjoern Hansen wrote:
On Tue, 4 Mar 2003, Josh Chamas wrote:
I thought it was interesting that Embperl 2 (barely) beat out PHP 4.3.0
on XSLT in both the XSLT Hello XSLT Big tests.
Why is that interesting? A bit more background would be
interesting. :-) (post it to the list maybe).
My
Hey,
I have published the latest Hello World benchmarks, available at:
http://chamas.com/bench/
Just updated are:
- PHP 4.3.0 built with domxml extensions for XSLT tests
- HTML::Embperl 1.3.6
- HTML::Mason 1.19
The PHP XSLT test are new, and the performance is similar is Embperl2 and
Dave Rolsky wrote:
On Mon, 14 Oct 2002, Josh Chamas wrote:
This is interesting. I should look into upgrading to perl 5.8 on
these tests see what difference there may be.
You might also see if it makes a difference if you run the tests for
a long enough time. I run them at least 60
Ed wrote:
Hi,
(as far as i can tell after a quick peek at the code and some debugging)
It looks like there is a bug w/ AxKit::run_axkit_engine() and/or
Apache::AxKit::Cache::_get_stats()
This is really great Ed. Adding the AxGzipOutput On config to the XSLT
tests in the benchmark does
Hey,
I updated the Apache Hello World Benchmarks with some major updates:
AxKit config fixed XSLT performance
Cocoon XSLT benchmarks added
Tomcat updated to 4.1.12
Check them out at http://chamas.com/bench/
Regards,
Josh
FYI, I reposted the benchmarks without the MaxRequestsPerChild 100 set
for HTML::Mason Template Toolkit, as it was only Embperl 2.x that
needed it.
Embperl 2.0b8 has still some real memory leaks. That's why it called beta.
Of course they will be fixed before the final release of 2.0.
Hey,
The Apache Hello World benchmarks are updated at
http://chamas.com/bench/
The changes that affect performance numbers include:
Set MaxRequestsPerChild to 1000 globally for more realistic run.
Set MaxRequestsPerChild to 100 for applications that seem to leak
memory which
Josh Chamas wrote:
Set MaxRequestsPerChild to 100 for applications that seem to leak
memory which include Embperl 2.0, HTML::Mason, and Template Toolkit.
This is a more typical setting in a mod_perl type application that
leaks memory, so should be fairly representative benchmark
On Tue, 15 Oct 2002, Perrin Harkins wrote:
Josh Chamas wrote:
Set MaxRequestsPerChild to 100 for applications that seem to leak
memory which include Embperl 2.0, HTML::Mason, and Template Toolkit.
This is a more typical setting in a mod_perl type application that
leaks memory,
Perrin Harkins wrote:
Josh Chamas wrote:
Set MaxRequestsPerChild to 100 for applications that seem to leak
memory which include Embperl 2.0, HTML::Mason, and Template Toolkit.
This is a more typical setting in a mod_perl type application that
leaks memory, so should be fairly
Dave Rolsky wrote:
I'm fairly sure, FWIW, that Mason does not have any memory leaks, as of
1.12. Pre-1.10 versions do have a _very_ slow memory leak, and 1.10 and
1.11 had that leak plus another, much nastier one.
Yes, Mason seemed pretty free of leaks when I tested it more today too.
On Mon, 14 Oct 2002, Josh Chamas wrote:
This is interesting. I should look into upgrading to perl 5.8 on
these tests see what difference there may be.
You might also see if it makes a difference if you run the tests for
a long enough time. I run them at least 60 seconds for these
.
So, I reran hello/bench.pl w/ AxGzipOutput On and sped axkit up quite a bit.
attached are some diffs and a couple of 1 sec bench.pl runs. Would be
interesting to see how axkit compares now?
Thanks,
Ed
On Mon, Oct 14, 2002 at 12:26:06AM -0700, Josh Chamas wrote:
Hey,
The Apache Hello World
Hi Josh,
On Tue, 30 Jul 2002, Josh Chamas wrote:
Thanks for the feedback still looking for more!
Well for one thing you're doing a great job. :)
Fo benchmarks to be more realistic, I feel that they need to include
chunks of code to do lookups in serious databases, put together very
complex
Dennis Haney wrote:
The bias in the test is even a little slanted towards the JSP
benchmarks since the trivial connection pooling I used there is
nothing like the Apache::DBI overhead in the mod_perl test, when I
could have just used a persistent global $dbh instead. ( maybe I
should? )
I
Perrin Harkins wrote:
To answer the original question, I don't think Apache::DBI is much
overhead at all. It amounts to little more than a hash lookup.
Certainly less work than the the thread synchronization required for
connection pooling.
My only problem with Apache::DBI for a
Josh Chamas wrote:
My only problem with Apache::DBI for a benchmark is its
default ping of the db per connect().
Oh, you're right I wasn't thinking about that. It is important in a
benchmark to be testing equivalent functionality as much as possible,
although it's very difficult to do.
I
Perrin Harkins wrote:
Despite the intentionally misleading nature of Microsoft's benchmark,
it did get me thinking about what sort of benchmarking options exist for
comparing languages and platforms. The Hello World and Hello 2000
benchmarks are pretty small (understandably so, given
PLEASE HELP.
I am trying to get Apache::Hello to work. I saved it as Hello.pm in
lib/perl/Apache. Below are my setup files and pertinent info. When I access
the virtual location (hello/world) from Apache's root directory, my browser
returns the following message: The document contains
On Mon, 17 Sep 2001 13:15:44 -0700
Ray and Lara Recendez [EMAIL PROTECTED] wrote:
# vi Hello.pm
Hello.pm 26 lines, 392 characters
package Apache::Hello;
# File: Apache/Hello.pm
use strict;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
$r-content-type('text
Ray and Lara Recendez wrote:
I am trying to get Apache::Hello to work.
...
#!/usr/local/bin/perl
Turn PerlWarn On as described here:
http://perl.apache.org/src/mod_perl.html#SWITCHES
Also try running Apache in single-user mode:
/usr/local/apache/bin/apachectl -X
This helps you pick up
On Thu, 10 Aug 2000, Ken Williams wrote:
To clarify - some handlers can be called using object-oriented
techniques, and some can't. The switch for this behavior is that the
handler is prototyped with ($$).
or with newer Perls:
sub handler : method {...}
Ah I C, said the Perl man!
Thank you for the clarification.
At 09:55 AM 8/10/00 -0500, you wrote:
[EMAIL PROTECTED] (G.W. Haywood) wrote:
Hi there,
On Wed, 9 Aug 2000, George Sanderson wrote:
PerlModule Apache::Hello
Location /hello/world
SetHandler perl-script
PerlHandler Apache::Hello
26 matches
Mail list logo
