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.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.
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.
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.The key is modperl. Modperl is a C program which is exceptionally fast. Most of my embperl code looks like this
Regardless, 2.x is faster than 1.x on the inline bit and I will take speed boost where I can. :-)
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.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 :)
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.
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).So...want to volunteer for building a benchmark suite? :-)Sure - I have a spare machine. We can make it an NYLXS project.
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.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.
Almost no web program, and unfortunately a lot of the current C programmer,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...
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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
