perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donovan Allen <all...@votehere.net>
Subject Re: What's going on with Embperl???
Date Wed, 17 Sep 2003 22:36:20 GMT
Ruben Safir Secretary NYLXS wrote:

>> I also have been concerned with Embperl  over the last year or so and 
>> I have considered migrating to Mason or even PHP.  I still use 1.x 
>> since it satisfies all that I have needed with the exception of speed 
>> (since Embperl is pretty much the slowest of the lot). 
>
>
>
> That is interesting, becayuse when I use mod_perl and objects with
> Embperl, I've been able to outperform both PHP,JSP, and Mason under 
> some fairly
> heavey loads.
>  
>
Well, to be honest I am going entirely off of a benchmark that someone 
provided a year or so ago to this list.  They built a fairly standard 
test that they deployed across 5 or 6 SSI implementations.  Embperl 1.x, 
as I recall, scored the lowest, but Embperl 2.x compared very very well 
to other technologies.  Gerald may have the details or maybe someone on 
the list still has the info (or is available in the archices for the list).

As to the details of what was tested...long ago left my memory.  I 
personally have no standard benchmark with which to compare. I would 
expect to see any Embperl that relies heavily on packages and objects 
out perform regular inline embperl due to caching.  It is possible that 
the test mentioned was not using cached modules.

I also have used Embperl for some very intensive applications and under 
load the performance does degrade (as does anything) and I personally 
looked forward to Embperl 2.x due to performance increase.  I also do 
most of my code in modules, even when it isn't the best fit, simply due 
to the cache.

Embperl 1.x is mostly implemented in perl, while PHP SSI, for example, 
is C or C++ I would imagine, so as long as a similar "library" cache was 
enabled, I seriously doubt that Embperl 1.x could match in speed in a 
"proper" benchmark, but I could be wrong.

As I recall, Mason performed slightly better in that benchmark than 
Embperl 1.x, but worse than 2.x.  Since the library caching is actually 
done in mod_perl (I think...), then I would imagine that either 1.x or 
Mason would similar.

Having looked through the Embperl 1.x code, I even found a few places 
where some speed increases could be gained by using other perl 
functionality that provides but more direct C interfaces.

So...want to volunteer for building a benchmark suite? :-)

> Once the objects are loaded, the programs respond nearly as fast as 
> the database allows.
>  
>
I have only benchmarked against PerlScript for IIS, which was miserable 
in performance and randomly produced unexpected results.  As far as I 
could tell, modules did not get cached, which was the killer for my test 
since most of it was module based.

> Ruben
>
>  
>
>> I would love to see Embperl really take off
>>   
>
>
> What I like about embperl is that it doesn't do much, and lets me get my
> pages activated, and then gets out of my way.  Since I write most code
> in Perl Objects with a class structure, I really don't need it to do 
> much.
>  
>
Agreed, which is the main reason I use it as well.  This is also 
somewhat the down side of Embperl, since your average web dev is afraid 
they might hang themselves with more rope...I guess. :-)

> As for sourceforge, I like that I can install EMBPERL vritually without
> thinking from CPAN.   
>
Why does SF exclude CPAN?  Stable releases could get bundled and pushed 
to CPAN...there are many projects that do this.  CPAN is a distribution 
tool, SF is a collaboration tool...like oranges and apples, but both are 
good in the same fruit salad.

> Ruben
>
>  
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message