Mailing List Archive

Perrin-
> I believe all the other systems (with the exception of Embperl which
> appears to use subs) turn everything into one sub and eval it. The HTML
> turns into print statements which stay in memory as part of the sub. How
> is what you're proposing different?

The primary difference is that the HTML will be held in c structures
that will cross reference with markers in the CVs that are built when
the script is evaled. I.e. the HTML is brought in once, and never
dealt with again. It is also held in native structures, no need to
deal with the opcode expedenture of dealing with a tied STDOUT. This
I think would provide a considerable improvement for scripts that have
a very small section that is dynamic. Not only that, but one of the
other features I'm thinking of bringing to the table is this:

<perl1>$Phhr->cachetime(15*60);</perl1>
<perl2>$Phhr->cachetime(0);</perl2>

Dig?, basically you can have seperate script namespace, and probably
even a <perl> which will apply to all script name spaces, i.e. bring
in your use's etc. So what happens is for 15 minutes the first script
would just be held in static cache, outputable at roughly 3-10 times
the speed of having the perl guy deal with it. This would be a useful
feature for a place like slashdot. So its marked as "good" for a
period of time, in the same place as the static html stuff, and when
it goes "bad" it is re-executed and held for another 15.

Example /.:
Parts of their page only updates every 15 minutes say... the articles.
But they still want to put your user name everytime to "Welcome you",
so they could tag 99% of their page as temporarily static, and the
rest as evaled for each request. Or even a cache based on the user...
this is more complex and more of a Session issue, but I'm just
bringing it up. (This isn't how /. does it, but they could based on
their structure)

> > My understanding is that
> > Mason, Embed, etc. are a bit slower than standard perl
>
> They are standard perl. (Well, Embperl has some C.) The reason code
> under Mason doesn't run as fast as a PerlHandler written straight to the
> Apache API is that it's doing quite a bit of setup work for you and
> resolving URLs, stat-ing files to see if they've changed, etc. In other
> words, it's the features that slow them down, not the basic architecture.

Not to mention Mason is written completely in Perl..., a pain or a
feature depending on how you look at it :). From my perspective, that
stinks, but I could see how many in the perl community may like that
as it's easy to change around. Pretty much everything I've written
for the engine I'm working on is in c, and this would be too.

Later,
Shane.

On Fri, 18 Feb 2000 shane@isupportlive.com wrote:
> Of course
> I'm not wedded to this syntax, so if anyone has better ideas, please
> pass them along.

Some systems (ePerl, for example) provide configurable syntax markers.
That's always a good way to go.

> The speed is added by there only being one single script that needs to
> be "evaled" by the mod_perl like engine, not only that but the HTML is
> stored in memory. The way its achieved is pretty boring c stuff, just
> a linked list with the static html inside native structures for
> phhttpd, and marker references that match up with the markers that are
> generated by the </perl> tags.

I believe all the other systems (with the exception of Embperl which
appears to use subs) turn everything into one sub and eval it. The HTML
turns into print statements which stay in memory as part of the sub. How
is what you're proposing different?

> My understanding is that
> Mason, Embed, etc. are a bit slower than standard perl

They are standard perl. (Well, Embperl has some C.) The reason code
under Mason doesn't run as fast as a PerlHandler written straight to the
Apache API is that it's doing quite a bit of setup work for you and
resolving URLs, stat-ing files to see if they've changed, etc. In other
words, it's the features that slow them down, not the basic architecture.

- Perrin

On Fri, 18 Feb 2000, Perrin Harkins wrote:

> Some systems (ePerl, for example) provide configurable syntax markers.
> That's always a good way to go.

Actually, there's something to be said for a fixed syntax. It makes it
quite a bit easier to exchange code for reading and for just distributing
prepackaged chunks of code for others to plug in and use.


-dave


/*==================
www.urth.org
We await the New Sun
==================*/

On Fri, 18 Feb 2000 shane@isupportlive.com wrote:

> Not to mention Mason is written completely in Perl..., a pain or a
> feature depending on how you look at it :). From my perspective, that
> stinks, but I could see how many in the perl community may like that
> as it's easy to change around. Pretty much everything I've written
> for the engine I'm working on is in c, and this would be too.

Whenever practical, I tend to prefer modules written in Perl to C. I know
Perl _much_ better than I know C and I prefer to be able to poke through
the code I use, either to change/add features or to improve performance or
whatever.


-dave


/*==================
www.urth.org
We await the New Sun
==================*/

>
> The speed is added by there only being one single script that needs to
> be "evaled" by the mod_perl like engine, not only that but the HTML is
> stored in memory. The way its achieved is pretty boring c stuff, just
> a linked list with the static html inside native structures for
> phhttpd, and marker references that match up with the markers that are
> generated by the </perl> tags.
>

Embperl can do this already (set option optKeepSrcInMem), but you have to be
aware that if you hold all html in memory, your httpd will grow very big
(especially if you have many pages, with less perl in it). Therefor Embperl
normaly let's the source on disk and keeps only the precompiled source in
memory. The OS diskcache will take cares that the most often used pages are
still in memory.

> Would anyone be interested in such a thing? My understanding is that
> Mason, Embed, etc. are a bit slower than standard perl,

That's, as Perrin already pointed out, because of the extra work they do for
you. In Embperl you can disable most of this if you don't need it.

Gerald


-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

> <perl1>$Phhr->cachetime(15*60);</perl1>
> <perl2>$Phhr->cachetime(0);</perl2>
>
> Dig?, basically you can have seperate script namespace, and probably
> even a <perl> which will apply to all script name spaces, i.e. bring
> in your use's etc. So what happens is for 15 minutes the first script
> would just be held in static cache, outputable at roughly 3-10 times
> the speed of having the perl guy deal with it. This would be a useful
> feature for a place like slashdot. So its marked as "good" for a
> period of time, in the same place as the static html stuff, and when
> it goes "bad" it is re-executed and held for another 15.
>

The next version of Embperl will be able to handle these caching issue. Also
I will do a rewrite of the parser so page execution will become even faster.

Gerald