PHP Smarty Templates - Re: [SMARTY] Smarty-Light

Author

Re: [SMARTY] Smarty-Light

Stefan

2004-07-11, 8:56 pm

> Smarty: 0.029031 seconds
> Smarty-Light: 0.011113 seconds

i would be more interested in the results of using Smarty and Smarty
with an opcode-cache in relation.

Paul Lockaby wrote:

> Hi everyone,
>
> I got a few hits for my site because of the previous thread entitled
> Smarty Light. I would reply to that thread specifically, but I'm using
> email and I don't have the originals to reply to, so you get to live
> with a new topic. Sorry.
>
> I did read the whole thread and it seems that there are some
> misconceptions about Smarty and speed. I'm not here to be down on
> Smarty, because it really is a revolutionary project for Template
> engines and PHP. It has a ton of features that really lots of people
> can't live without. It also inspired me and provided a code base for
> me to start from when I decided to fork Smarty and make my own.
>
> Here is why I decided to fork Smarty: speed and features. I won't go
> into the features, because that's really not the point of this thread.
> I added a few that I wanted that were not entertained by the
> maintainers of Smarty and I removed a ton of features that Smarty had
> that I never used. That did, in fact, make the code base much faster.
>
> I'm not sure about PHP5, but with PHP4, compilation time is directly
> related to the size of the PHP file and the complexity of any classes
> you have. As much as PHP tries to be an object oriented language, you
> still have to realize that every time a PHP page is called, it is
> recompiled by PHP and that takes time. Even if you only use three
> lines of your code and it exits on the fourth, if the code is 60kb, it
> will compile all 60kb.
>
> That was the problem I saw with Smarty. The two files it uses to
> create templates are 65kb and 88kb. That's a lot of code if you just
> have a simple template. If you look at what I pared that down to, I
> only have 14kb and 27kb. Trust me, it makes a difference in compile
> times. But you don't have to trust me, I'll show you some unscientific
> numbers I just got off of my test webserver which is a private, NATed
> 466MHz Celeron with 512MB RAM and a 7200RPM HDD running apache 1.3.31
> and PHP 4.3.7.
>
> First test page, doesn't load a thing, just instantiates the template
> object.
> Smarty: 0.029031 seconds
> Smarty-Light: 0.011113 seconds
>
> Second test page, displays a compiled page with two variables and
> nothing else.
> Smarty: 0.053641
> Smarty-Light: 0.023038
>
> The pages used to test the second numbers is available here:
> http://www.paullockaby.com/pub/template_test.zip
>
> Now granted, those numbers are small to begin with, but start loading
> lots of pages and it adds up.
>
> Of course, I realize that this thread is really off topic for this
> forum and that I'll probably get whacked for posting stuff about my
> own template engine in here, but I felt it necessary to point out that
> class instantiation is slow and gets slower proportionally to the
> amount of code *and comments* in the class.
>
> Thanks for your time.
>
> Paul Lockaby
>

Paul Lockaby

2004-07-12, 3:59 am

Some of us don't have the luxury of having root access to our own
server, nor the monetary resources to purchase an accelerator.

Paul Lockaby
On Jul 11, 2004, at 7:30 PM, Stefan wrote:

>
> i would be more interested in the results of using Smarty and Smarty
> with an opcode-cache in relation.
>
>
> --
> Smarty General Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Ara Anjargolian

2004-07-12, 8:59 am

I personally don't think that the existence of opcode-cache gives
license to arbitrarly add more and more features and code to a program
just because "it doesn't matter anyway". Performance is not the only
metric that matters.

More code and more complexity invariably leads to more bugs, more
instability. This is always the case no matter the talent of the
developers.

But this is an argument that has no resolution. The beauty of open
source is that if you don't like it, you can fork it and roll your
own. And I guess every person and company will make a choice of
what to use that's best for them.

-Ara Anjargolian

Stefan wrote:

>
> i would be more interested in the results of using Smarty and Smarty
> with an opcode-cache in relation.
>

Stefan

2004-07-12, 8:59 am

You're neither need root access, nor not a cent. mmcache i.e. is
licensed under the gnu gpl. So can be used without any fee. Using it on
a safe-mode php version is also possible, if you may execute CGIs as
well. You bypass the systems php Version using your own, if you run your
scripts as cgi. Using this approach you can specify your own php.ini,
can activate, or deactivate safe-mode und finally can load extensions.

Drawback could be, that your Scripts have to get a different suffix
(ugly). Perhaps .php4.cgi . or .cgi, or whatever your provider has set
up. And ... you have to compile php in fcgi mode (most versions of php,
are compiled for cli mode) and perhaps to link it static against the
used libraries. Because of that the executable could become quiet big
(~10 meg). Using -Os (optimization for size) reduces the size to nearly
~1.0 meg. ...

Some technical gimmicks, but it's not a question of money ... .

Paul Lockaby wrote:

> Some of us don't have the luxury of having root access to our own
> server, nor the monetary resources to purchase an accelerator.
>
> Paul Lockaby
> On Jul 11, 2004, at 7:30 PM, Stefan wrote:
>
>

Paul Lockaby

2004-07-14, 3:57 am

Alright, it's been a while since I've researched optimizing things, and
a few years ago it did cost money to get an accelerator that was any
good. So you win on the cost argument.

However, running your own CGI is a horrible security risk, and not to
mention inefficient (probably removing any effect the accelerator would
have in the first place). However, I do believe the point is being
missed. I think that one shouldn't feel that one can write sloppy or
large code simply because there are fast CPUs or simply because one is
using an accelerator. One should always strive to write compact, fast,
and efficient code. That is what I tried to do with Smarty by creating
Smarty-Light.

The whole point of me emailing this list, however, was not for the
above flame. Some of you may remember me from back in late 2002 and
early 2003. I used to use Smarty and I even submitted some patches --
my name appears in the changelog a couple times. However, the reason I
forked Smarty to create Smarty-Light was because I didn't like some of
the syntax issues (backticks for concatenation? why not use the PHP and
Perl method of putting a dot between strings?) and because Smarty was,
and still is, in my opinion, bloated and slow. That's why I forked it.
And I wrote it with speed in mind, doing benchmarks with every major
change. Code size definitely makes a difference with speed and PHP
objects are really slow.

However, the point of my emailing this list was to point out that small
file sizes and compact code and removing features that you don't use
really does make a difference in speed -- more than twice as fast in
the examples I provided. That was the point of this email. Sorry to
bother all of you, and Monte/Messju, you guys really do maintain a good
piece of software here, otherwise I wouldn't have forked it and instead
would have forked one of the other bazillion template engines available
for PHP. But a speed demon it is not.

Paul Lockaby

On Jul 12, 2004, at 6:27 AM, Stefan wrote:

> You're neither need root access, nor not a cent. mmcache i.e. is
> licensed under the gnu gpl. So can be used without any fee. Using it
> on a safe-mode php version is also possible, if you may execute CGIs
> as well. You bypass the systems php Version using your own, if you run
> your scripts as cgi. Using this approach you can specify your own
> php.ini, can activate, or deactivate safe-mode und finally can load
> extensions.
>
> Drawback could be, that your Scripts have to get a different suffix
> (ugly). Perhaps .php4.cgi . or .cgi, or whatever your provider has set
> up. And ... you have to compile php in fcgi mode (most versions of
> php, are compiled for cli mode) and perhaps to link it static against
> the used libraries. Because of that the executable could become quiet
> big (~10 meg). Using -Os (optimization for size) reduces the size to
> nearly ~1.0 meg. ...
>
> Some technical gimmicks, but it's not a question of money ... .
>

Markku Niskanen

2004-07-14, 8:59 am

Paul,

>and still is, in my opinion, bloated and slow. That's why I forked it.=20
>And I wrote it with speed in mind, doing benchmarks with every major=20
>change. Code size definitely makes a difference with speed and PHP=20

May I ask you what the most significant parts you left=20
out of the code were? And another thing: If you use the
same subset of template features with the "bloated" code
and your "thin" code, where do the speed difference com
from? Loading the base class? Other optimized places?

Markku

Vonleigh Simmons

2004-07-14, 8:58 pm

> One should always strive to write compact, fast, and efficient code.

Or one could strive for well written, orthogonal, easily maintainable
and expandable code; then later strive for performance. Early
optimization is the root of all evil; but this is just my philosophy
and it's great that one as a programmer has many philosophies to choose
from.

In my case I rely on objects, straight scripts or whatever is more
appropriate in my PHP, that allows me to do more with less. After I'm
done I profile and if anything is too slow I can rewrite or send off to
another language like perl.

During my profiling smarty hasn't been the bottleneck. In fact it has
alleviated many by using the caching, so that the slower operations
only need to be generated once every month in some cases. I do have
mmcache installed.

This is not to say that your project doesn't have merit. In an
environment with an extreme load, where one can't get more hardware or
more hardware doesn't help, or when the content changes so quickly that
caching isn't very effective; if one profiles the code and it turns out
that smarty is the slowest component, then your project would fit
perfectly. I could think of friendster where they have had serious
performance trouble with both java and php.

> because I didn't like some of the syntax issues (backticks for
> concatenation? why not use the PHP and Perl method of putting a dot
> between strings?)

I have to agree with that. The dot between strings is much more
friendly. Any idea why it's not in smarty?

> But a speed demon it is not.

In my case it doesn't matter. One has to find the slowest components
and optimize those first to net the greatest speed difference. In my
case it hasn't been smarty so far.

Maybe someone can do some tests with mmcache enabled.

Vonleigh Simmons
<http://illusionart.com/>

Boots

2004-07-14, 8:58 pm

--- Vonleigh Simmons <nospam@illusionart.com> wrote:
>
> I have to agree with that. The dot between strings is much more
> friendly. Any idea why it's not in smarty?

Because of BC, I suppose. Smarty already uses dot-notation for
array-key access. Dot-notation concatenation doesn't really have a long
history in other languages, though it might be a surprise for people
with only PHP. Also, unlike PHP, Smarty doesn't require literal strings
to be quoted which complicates the matter. Backticks are actually more
similar to PHP's {} string replacer.

I guess we all have something that niggles at us in these regards.
What I don't like is the -> notation for attributes/methods instead of
dot notation. (oh yeah, and modifiers can't have white spacing)

Monte Ohrt

2004-07-14, 8:58 pm

Back in the very early days of Smarty when the syntax was still
developing, I actually wanted to stick to PHP syntax as close as
possible, mostly because it was already well understood by PHP
programmers and would be easier to integrate new functionality. But
somewhere along the way it was decided to make a new syntax instead. The
thinking was that this is a template engine, not a PHP program. The
template syntax should be as simple and intuitive as possible, and since
we have a chance to do that why not do things like:

{$foo.bar.blah}

instead of:

{$foo['bar']['blah']}

Also when it came to things like section loops, keeping the syntax to a
minimum meant stepping into PHP syntax boundaries for other uses. ( eg.
$foo[bar][blah] )

Well as Smarty evolved it certainly has shown its consequences of going
this route. I'm thinking that Smarty will eventually turn a new leaf and
be re-engineered from scratch (and that day may draw nearer as PHP 5
comes to life), and all the engine idioms can then be analyzed and
decided upon.

Monte

boots wrote:

>--- Vonleigh Simmons <nospam@illusionart.com> wrote:
>
>
>
>Because of BC, I suppose. Smarty already uses dot-notation for
>array-key access. Dot-notation concatenation doesn't really have a long
>history in other languages, though it might be a surprise for people
>with only PHP. Also, unlike PHP, Smarty doesn't require literal strings
>to be quoted which complicates the matter. Backticks are actually more
>similar to PHP's {} string replacer.
>
>I guess we all have something that niggles at us in these regards.
>What I don't like is the -> notation for attributes/methods instead of
>dot notation. (oh yeah, and modifiers can't have white spacing)
>
>
>

Stefan

2004-07-14, 8:58 pm

only by the way, because of the final release of php5.

php5 spawns a method to load classes on demand using the __autoload
function. A callback, which is called, when php5 doesn't found a used
class. Theoretically you could now split the big bunch of smarty code
into two pieces. One lightweight caching module, and the other big, but
flexible, smarty parser, compiler, ... . So only if no cached template
is found, the parser would be loaded. Could save a lot of php parsing
time. On the other hand, php5 is not established as much, as something
like that could be implemted, without mechanisms, forcing php4 and
below, to ignore that code. And ... i have absolutly no idea how php5
handles multiple __autoload definitions. A reserved __autoload callback
could be bring much more problems as it actually solves.

But is there no other possibilty to load the smarty code internally on
demand. Perhaps using require(_once), or something?

Vonleigh Simmons wrote:

>
>
> Or one could strive for well written, orthogonal, easily
> maintainable and expandable code; then later strive for performance.
> Early optimization is the root of all evil; but this is just my
> philosophy and it's great that one as a programmer has many
> philosophies to choose from.
>
> In my case I rely on objects, straight scripts or whatever is more
> appropriate in my PHP, that allows me to do more with less. After I'm
> done I profile and if anything is too slow I can rewrite or send off
> to another language like perl.
>
> During my profiling smarty hasn't been the bottleneck. In fact it
> has alleviated many by using the caching, so that the slower
> operations only need to be generated once every month in some cases. I
> do have mmcache installed.
>
> This is not to say that your project doesn't have merit. In an
> environment with an extreme load, where one can't get more hardware or
> more hardware doesn't help, or when the content changes so quickly
> that caching isn't very effective; if one profiles the code and it
> turns out that smarty is the slowest component, then your project
> would fit perfectly. I could think of friendster where they have had
> serious performance trouble with both java and php.
>
>
>
>
> I have to agree with that. The dot between strings is much more
> friendly. Any idea why it's not in smarty?
>
>
>
>
> In my case it doesn't matter. One has to find the slowest
> components and optimize those first to net the greatest speed
> difference. In my case it hasn't been smarty so far.
>
> Maybe someone can do some tests with mmcache enabled.
>
>
> Vonleigh Simmons
> <http://illusionart.com/>
>

Robert Amos

2004-07-14, 8:58 pm

To some extent this happens already, Smarty will only load the
compiling class (Smarty_Compiler) if it needs to parse and load the
page, we've discussed stripping it back further and dropping it to a
caching only class on the mailing lists before, can't really remember
what became of that though.

-bok

On Thu, 15 Jul 2004 00:52:12 +0200, Stefan <e.tuli@gmx.de> wrote:
> only by the way, because of the final release of php5.
>
> php5 spawns a method to load classes on demand using the __autoload
> function. A callback, which is called, when php5 doesn't found a used
> class. Theoretically you could now split the big bunch of smarty code
> into two pieces. One lightweight caching module, and the other big, but
> flexible, smarty parser, compiler, ... . So only if no cached template
> is found, the parser would be loaded. Could save a lot of php parsing
> time. On the other hand, php5 is not established as much, as something
> like that could be implemted, without mechanisms, forcing php4 and
> below, to ignore that code. And ... i have absolutly no idea how php5
> handles multiple __autoload definitions. A reserved __autoload callback
> could be bring much more problems as it actually solves.
>
> But is there no other possibilty to load the smarty code internally on
> demand. Perhaps using require(_once), or something?
>
>
>
>
> Vonleigh Simmons wrote:
>
>
> --
> Smarty General Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Thorsten Suckow-Homberg

2004-07-14, 8:58 pm

>Theoretically you could now split the big bunch of smarty code
> into two pieces. One lightweight caching module, and the other big, but
> flexible, smarty parser, compiler, ... . So only if no cached template
> is found, the parser would be loaded.

I personally think this is a good idea. Since the autoload-function is only declared once in a script and takes the classname as a
param, multiple including of diferent classes is not that complcated: Simple put a switch-statement into the function like this:

<?php
function __autoload($className) {

switch ($className) {
case "smartyLight":
include_once "smartyLight.class.php";
break;

case "smarty":
include_once "smarty.class.php";
break;
}
}
?>

But: how do you want to decide which class you want to instantiate (for example u want to check if a cached exemplar exists and want
to load this)?

Things should then get stripped down: A smarty base-class which holds only neccessary information for cached templates (fetching
them etc.) and the main-class (which we all know as smarty right now) that extends from this base-class and puts more methods and
functionality to it. You then would require in every script you want to check for cached templates smartyBase.class.php like this:

<?php

// get the lightweight-class of smarty
require_once "smartyBase.class.php";

// call a static method to check for cached exemplars:
$cache = SmartyBase::checkIfTemplateIsCached("nameOfTemplate");

// $cache will now hold the cached template as a string or false if not cached
if ($cache !== false) {
echo $cache;
die();
}

// cache was false, no cached template, start loading smarty and do usual stuff with it...
$smarty = new Smarty;
....

?>

Just my two cents on it, while refactoring maybe something one could think about...

Regards

Thorsten

Paul Lockaby

2004-07-14, 8:58 pm

Features I took out:
* pre/post/output filters
* include_php and php tag, smarty-light only processes php directives
in if-then statements and nowhere else
* section tag (I use foreach for all my section needs)
* security features
* error handling, doesn't die very gracefully
* no support for objects or classes
* no support for template resources, templates must come from a file

Smarty-Light still compiles and caches and runs config files. After
going through most of the Smarty code, I probably ended up rewriting
more than 80% of it. In the end, the vast majority of code was new and
I used Smarty more for a design reference than a code reference. I got
my speed from rewriting and optimizing routines.

I'm curious about PHP5 and plan to test it out to see what kind of
speed differences it makes on object oriented programming. It offers a
lot of features that make OOP a lot more mature, but I'm hesitant to
take advantage of them until more servers upgrade to PHP5, though I
feel that perhaps leaving the PHP4 version available and starting work
on a PHP5 version while backporting compatible changes would be
feasible.

Paul Lockaby
On Jul 14, 2004, at 4:12 AM, Markku Niskanen wrote:

> Paul,
>
>
> May I ask you what the most significant parts you left
> out of the code were? And another thing: If you use the
> same subset of template features with the "bloated" code
> and your "thin" code, where do the speed difference com
> from? Loading the base class? Other optimized places?
>
> Markku
>
> --
> Smarty General Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Stefan

2004-07-14, 8:58 pm

> // call a static method to check for cached exemplars:
> $cache = SmartyBase::checkIfTemplateIsCached("nameOfTemplate");

i would hate it. ;o)

A solution could be to delegate the responsability of creating the cache, compilation to another object. The idea behind is to hide/enpasulate as most as possible. The user shouldn't care, wheter the template is loaded from cache, is compiled, ... .

I took a look on the source of Smarty.class.php and it's quiet hard to understand, even with phpdoc. Some functions (ie. Smarty->fetch with ~ 200 lines) seem to tangled to me. But actually i'm not a smarty code developer and such a core-redesign would cos
t a lot of time, manpower and testing. And i don't think the core-team is very interessted to redesign the hole in the near future. ;o)

so ... g9

Thorsten Suckow-Homberg wrote:

>
>I personally think this is a good idea. Since the autoload-function is only declared once in a script and takes the classname as a
>param, multiple including of diferent classes is not that complcated: Simple put a switch-statement into the function like this:
>
><?php
>function __autoload($className) {
>
> switch ($className) {
> case "smartyLight":
> include_once "smartyLight.class.php";
> break;
>
> case "smarty":
> include_once "smarty.class.php";
> break;
> }
>}
>?>
>
>But: how do you want to decide which class you want to instantiate (for example u want to check if a cached exemplar exists and want
>to load this)?
>
>Things should then get stripped down: A smarty base-class which holds only neccessary information for cached templates (fetching
>them etc.) and the main-class (which we all know as smarty right now) that extends from this base-class and puts more methods and
>functionality to it. You then would require in every script you want to check for cached templates smartyBase.class.php like this:
>
><?php
>
>// get the lightweight-class of smarty
>require_once "smartyBase.class.php";
>
>// call a static method to check for cached exemplars:
>$cache = SmartyBase::checkIfTemplateIsCached("nameOfTemplate");
>
>// $cache will now hold the cached template as a string or false if not cached
>if ($cache !== false) {
>echo $cache;
>die();
>}
>
>// cache was false, no cached template, start loading smarty and do usual stuff with it...
>$smarty = new Smarty;
>...
>
>?>
>
>Just my two cents on it, while refactoring maybe something one could think about...
>
>Regards
>
>Thorsten
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Boots

2004-07-15, 4:00 am

--- Stefan <e.tuli@gmx.de> wrote:
>
> i would hate it. ;o)

While we are kicking ideas around, I've had a design in my head that
focuses around the new Streams API. Filters and such are left to PHP
land. Meanwhile, there would be separate stream wrappers for the main
file types (template resources, compiled files, cache images) and you
would subclass them to create your own resource handlers. Even
display() becomes redundant--you'd use a standard PHP include() and/or
get_file_contents for fetch(). I attempted a PHP4 prototype of this
awhile back but I realized that several PHP5 only stream features are
required to make a real go at it. FWIW, I used a callback metaphor to
avoid the issue of making assignments (if a template is non-cached, it
makes callbacks to get template assignments--otherwise it just reads
the cache) but contexts would probably be better. I don't know how it
would work out performance wise in the end, but I satisfied myself that
it would at least be doable.

Another thing about this design opportunity is that the compiler
becomes more of a plugin--or possibly even a filter that can be applied
to the stream. Concevievably you would be able to chain compilers (for
example, to separate back-end and front-end). Evidently this decouples
Smarty's internals making it more reasonable that someone might target
specific slow portions and convert them either a C Stream Wrapper or C
module.

Well, that's just ideas and though they are PHP5 specific, they have
nothing/little to do with the new object model. Monte's notion to start
over with a reevaluation/design in the face of PHP5 makes sense to me.

Perhaps we should move this to smarty-dev@lists.php.net?

xo boots

Jochem Maas

2004-07-15, 4:00 am

Thorsten Suckow-Homberg wrote:
>
>
> I personally think this is a good idea. Since the autoload-function is only declared once in a script and takes the classname as a
> param, multiple including of diferent classes is not that complcated: Simple put a switch-statement into the function like this:
>
> <?php
> function __autoload($className) {
>
> switch ($className) {
> case "smartyLight":
> include_once "smartyLight.class.php";
> break;
>
> case "smarty":
> include_once "smarty.class.php";
> break;
> }
> }
> ?>

somebody pointed out the problem with multiple __autoload() definitions
(not possible.) so that is basically ruled out. although Smarty already
has a fileloading functionality for the modifiers, I don't see why that
can't be used in the first instance for classes.

>
> But: how do you want to decide which class you want to instantiate (for example u want to check if a cached exemplar exists and want
> to load this)?
>
> Things should then get stripped down: A smarty base-class which holds only neccessary information for cached templates (fetching
> them etc.) and the main-class (which we all know as smarty right now) that extends from this base-class and puts more methods and
> functionality to it. You then would require in every script you want to check for cached templates smartyBase.class.php like this:
>
> <?php
>
> // get the lightweight-class of smarty
> require_once "smartyBase.class.php";
>
> // call a static method to check for cached exemplars:
> $cache = SmartyBase::checkIfTemplateIsCached("nameOfTemplate");
>
> // $cache will now hold the cached template as a string or false if not cached
> if ($cache !== false) {
> echo $cache;
> die();
> }
>
> // cache was false, no cached template, start loading smarty and do usual stuff with it...
> $smarty = new Smarty;
> ...
>
> ?>

I would suggest object aggregation, to avoid te above:

<?

class Smarty
{
private $compiler;

public function display($tpl)
{
if (SmartyBase::checkIfTemplateIsCached($tp
l)) {
$this->compiler = new SmartyCompiler( $this );
$this->compiler->doMagic($tpl);
// unset( $this->compiler ); // ?
}

// forgive me the internal of smarty
// escape me right now.
$this->_showEmWhatYaGot();
}
}

?>

things like security, 'advanced' syntax (e.g. php, section tags) could
be aggregated also and possibly included.

>
> Just my two cents on it, while refactoring maybe something one could think about...
>
> Regards
>
> Thorsten
>

Paul Lockaby

2004-07-15, 4:00 am

If anyone is interested in discussing or using Smarty-Light, I have
released a new version today and created a new mailing list at
http://sourceforge.net/projects/smarty-light

Thanks for listening to me and taking my comments into consideration.

-Paul Lockaby

Markku Niskanen

2004-07-15, 4:00 am

On Wed, 14 Jul 2004 19:19:20 -0400, you wrote:

>Features I took out:
>* pre/post/output filters
>* include_php and php tag, smarty-light only processes php directives=20
>in if-then statements and nowhere else
>* section tag (I use foreach for all my section needs)
>* security features
>* error handling, doesn't die very gracefully
>* no support for objects or classes
>* no support for template resources, templates must come from a file

All this makes me wonder where the speed difference really
comes from. Unused features only affect the class loading
time and if a kept feature (a loop, for instance) is used=20
the same way it should take the same CPU cycles to run.

If the 'section' code, for instance is in the class but I do not
use it it should only use CPU when parsing/compiling the
class.=20

If there is very little other optimization a 'light' version should
not be significantly faster after loading the class. Am I missing
something?

Markku

Paul Lockaby

2004-07-15, 8:58 am

On Jul 15, 2004, at 3:24 AM, Markku Niskanen wrote:

> All this makes me wonder where the speed difference really
> comes from. Unused features only affect the class loading
> time and if a kept feature (a loop, for instance) is used
> the same way it should take the same CPU cycles to run.
>

Loading of the class is a significant difference, however, that's not
all there is to it. If I don't use pre/post/output filters, I don't
have to check for them and I don't have to run them. If I don't use
resources, I don't have to see if they're there. If I don't use
security, then I don't have to check for it. If I don't support classes
and objects, then my regular expressions don't have to work as hard.
Etc.

The features I took out are things that I felt were frivolous and not
needed for my purposes and the purpose of the average template engine
user.

> If the 'section' code, for instance is in the class but I do not
> use it it should only use CPU when parsing/compiling the
> class.
>
> If there is very little other optimization a 'light' version should
> not be significantly faster after loading the class. Am I missing
> something?
>

You are missing and not realizing just how slow PHP is at loading and
compiling classes and associated code. Remember, without an
accelerator, PHP recompiles each script every time it is invoked. The
more code there is, the more there is to compile and the longer it will
take the script to actually start. Not to mention I did do a lot of
optimization to the original Smarty code.

> Markku

Markku Niskanen

2004-07-15, 8:58 am

On Thu, 15 Jul 2004 06:20:28 -0400, you wrote:

>and objects, then my regular expressions don't have to work as hard.=20
>Etc.

All right... so the checkings require CPU time? I suppose you have
done proper profiling so I will not argue :)

>You are missing and not realizing just how slow PHP is at loading and=20
>compiling classes and associated code. Remember, without an=20

No, I am not. I have done some experimening as well and do
know the difference. I did some testing and found out the following
average class loading times (sec, PHP5, P300,Linux), please=20
note that they ONLY apply to loading the class and will be nil
in an opcode-cached environment.

Smarty.class.php 0.05109=20
Smarty.class.php (no whitespace) 0.04538
class.template.php (Smarty-Light) 0.02190
class.template.php (no whitespace) 0.02118

So there seems to be a difference. As for running real-life apps
I cannot test your class as it lacks several features that I use in=20
ny every application and cannot live without. Those who do=20
not need them may benefit from your version.

Markku

Sponsored Links