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 Thu, 18 Sep 2003 00:59:53 GMT
Ruben Safir Secretary NYLXS wrote:

>Yes - In my experience I had a JSP programmer test his code for a scheduling
>function against my code in EMBPerl and modules.  After the first hit,
>I was much faster than he was.  I've done similar things with PHP coders
>and even coded the PHP myslef.
>
>After the first hit, and when EMBPERL has it's logging level lowered,
>is was outstandingly fast, especially with large data grabs, and pages
>which were repeated.  OTOH, my HTTPD processes grow large...and I'm thrilled
>to death about that.  
>
Like leaking memory large or just larger?  Unfortunately, the latter, as 
you well know, is going to happen to some degree with any library cache 
technology.  

Not sure how perl compares to other script languages, but so many perl 
modules use things like Exporter and such that add huge memory overhead 
for something that they use a fraction of and could have made roughly 
the same thing in a fraction of the code.  It makes ugrades more 
difficult, but you may be able to get a ton of memory back by replacing 
some of the more common use modules in 3rd party modules with your own 
trimmed down (and unique name space) versions.  But then CPAN becomes a 
little less handy. :-)  I did this and got my memory usage down by 
nearly 35% per httpd child instance.

I also have come across many CPAN modules that leak memory, which is 
really great in mod_perl or other daemon scripts.  Infact, out of the 5 
memory leaks I have had on Embperl projects, one was in my own module, 
the others were in 3rd party modules.  Something to keep in mind and 
watch out for.

>The key is modperl.  Modperl is a C program which
>is exceptionally fast.  Most of my embperl code looks like this
>
>  
>
Agreed, as much as you can run through just modperl, the faster you get. 
 I do use alot of inline perl for the actual interface display, and this 
is where I would really enjoy faster parsing in Embperl.  On the other 
hand, I rarely do that in new projects, except out of laziness, but 
instead use a homemade template module.

Regardless, 2.x is faster than 1.x on the inline bit and I will take 
speed boost where I can.  :-)

>>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.
>>    
>>
>
>Perhaps this is good if you think you can code it better than Mike
>Schwern and Lincoln Stein :)
>  
>
No, I mean using faster ways with standard perl that use less "magic" 
and are closer to just a c library call.  Most perl programs and 
programmers are frought with using the easier to use functions and then 
abandon the language for a project where performance was bad.  In most 
cases like this where I took a look at what they were doing, I was able 
to get the performance much much closer to C equivalent speeds.

One simple example is IO, especially the I bit. :-)  Try reading a 80GB 
file with pattern matches every line and substitution using <FILE> or 
even IO->readline().  By using sysread() and using patterns matches to 
divided lines into $1 etc, you get somewhere around 11x the speed.

>>So...want to volunteer for building a benchmark suite? :-)
>>
>>    
>>
>Sure - I have a spare machine.  We can make it an NYLXS project.
>  
>
Excellent!  That will save me the effort of having to do benchmarks of 
my own to decide if I stick with Embperl (which happens nearly everytime 
I check embperl.org to find little has happened in the last 3-4 months).

>>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.
>>    
>>
>
>I can't be involved with the stupidity of closed software, especially
>incredibly bad software like IIS.
>  
>
Fortunately, due to the bad performance of PerlScript, I got to avoid 
this sort of stupidity as well.  I would never volunteer for that kind 
of pain and torture, but it was dictated that I try.  Narrow miss...whew.

>Almost no web program, and unfortunately a lot of the current C programmer,
>understand the basics of good program design.  No set of programmers hang 
>themselves more frequently than the PHP folks.  There might be some truly
>good ones, but I've yet to meet them and they are far and few inbetween.
>There is a big difference between writing good code, and being proficient
>in hacking code.
>
Agreed.  I work with one of these people, and most of the time I want to 
strangle him with his mangled code.  But then, he is a IIS+ASP drone, so 
I guess I shouldn't expect more.  Anyway...back to topic...

Still, it would be nice to point at some numbers that showed Embperl 
using inline perl matching or beating PHP and others.  Hard enough as it 
is to sell SSI perl to a company or manager when PHP, ASP, .NET, (etc) 
are the buzz-technologies of the day without having good data to give a 
non-biased reason to use it as well.  

Embperl is not the powerhouse behind any "well known" sites, and even 
Mason has Amazon and a few others on its list.

Really no good reason why Embperl does not have a big name or two on its 
list other than lack of exposure (books,geek sites, etc) and the dev 
progress and momentum to produce and maintain excitement in the user base.

Alas, why we have this thread...

I don't care about such things, but business does, and well, that is how 
I make my living. :-)  If I had to look for a job tomorrow, Amazon would 
be on the list since I am in that territory, and they are entrenched in 
Mason.  Possible that the hiring manager would never have heard of 
Embperl and that the same skills apply.

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Mime
View raw message