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).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.
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.
RubenAgreed, 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. :-)
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.
As for sourceforge, I like that I can install EMBPERL vritually withoutWhy 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.
thinking from CPAN.
Ruben
