Change <? echo ... ;> to <?=..?> / Small, but wide performance change.

[Ruby]

I noticed that a lot of core and non-core developers use technique Nr. 1 below a lot.  And, as far as I read it somewhere, I believe that technique Nr.2 below is considered to have minor performance boost in php.  (It also is a bit of lesser code).

Technique Nr1:                 <? echo (some 1 line-php code here) ;?>

Technique Nr2:                 <?=(some 1 line-php code here)?>

 

So, isn't is better to adapt this code-guideline and do a regular-expression find-and-replace on the whole joomla code?  It might turn out to be a wide performance boost (because it is used so many times).

[Joseph LeBlanc]

The problem with Nr.2 is that short tags must be turned on for it to work. By default, PHP is configured to have short tags off. While most hosts I've encountered turn it on, I've still occasionally run into one with it off.

-Joe

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Nabyl]

It's good to boost the performance of the J! core, but we must not neglect the portability of the code.

2009/12/24 Joseph LeBlanc <con...@jlleblanc.com>

--

_________________________________
Nabyl

[Niels Braczek]

Ruby schrieb:

> Technique Nr1: <? echo (some 1 line-php code here) ;?>
> Technique Nr2: <?=(some 1 line-php code here)?>

The only correct (because independent of individual server
configuration) is a third version:

Technique Nr3: <?php echo (some 1 line-php code here); ?>

Regards,
Niels

[Stian Didriksen]

@Niels, careful with using words like "only correct".
As you forgot the fourth variation. When the php code are on just a
single line, you don't need the semi-colon:

<?php echo (some 1 line-php code here) ?>

[Stian Didriksen]

Btw, you can actually use shorthand code ( <?= ?> ) in the Nooku
Framework, as it'll simply change them to <?php echo ?> if the server
got them shortags turned off :)

On Dec 25, 5:10 am, Niels Braczek <nbrac...@bsds.de> wrote:

[Hristo Genev]

Let me share my opinion.
I had a few php shorthand tags in my component's code, when I released
it. I was not aware, I thought I replaced them all. And guess what
happend ... 10% of the users downloaded the component cried out
looooooud. If server is not configured to use <?, you may get all
your php code outputed in the browser.

[Niels Braczek]

Stian Didriksen schrieb:

> @Niels, careful with using words like "only correct".

I am...

> As you forgot the fourth variation. When the php code are on just a
> single line, you don't need the semi-colon:
> <?php echo (some 1 line-php code here) ?>

Yes, this form exists, but that was not the point. We're talking about
short open tags.

Regards,
Niels

[mic]

I am not shure what for this thread shall be good?

Discussing some 'bad' practices?
Performance boost (while a regular expresssion is sooo fast at all)?
Breaking the compatibility?
Making problems if the directive short_open_tag is DISabled (as it is
on all of my servers)?
Having/making troubles if XML will be used in conjuction with php?

Really see no sense in this discussion - see also http://at2.php.net/manual/en/ini.core.php.

And @Ruby: I do NOT see this technique at many develoepers (and I am
happy about that!), but maybe you can highlight me/this - show me
where in the core is this done (3PD is not from interest for me as
there are too many lousy written scripts out there)?

[dukeofgaming]

FTR: The Kohana MVC framework asks for this as a requirement since PHP has had this enabled by default for quite some time.

It would be nice that Joomla included an optional survey during the installation to find out this kind of stuff

[Hannes Papenberg]

We have a pretty strict set of coding rules and these strictly forbid
the use of short open tags and I don't see a reason why we should change
this rule. We also try to make our code as readable as possible,
especially for novice users/developers, thus we try to use the most
common coding practices and especially not use shortened notations. We
are using one shortened notation, the "inline"-notation for if-clauses,
however even with this single exemption of the rule I'm not really sure
if it is wise. On the other hand it makes the code a lot shorter in a
lot of cases. I'm actually very unhappy that we are using yet another
notation for the if-clause in our layouts. I think its actually an
inconsistency in our coding style and does not really help with
readability. In the end it was a concession to the designers, since it
was deemed easier to read for them. I actually doubt it...

As I said, our coding style practices are aimed at readability. Yes,
there may be and most certainly are more performant coding styles out
there, but we are talking about the tiniest fractions of performance
improvements, barely measurable. I doubt that we would even register a
1% performance gain in the overall run and if we are talking about a
mission-critical application that actually depends on this <1%
performance gain, I'd say you either are using the wrong tool (or coding
language) or you aren't throwing enough hardware at it.

What I'm saying is: Could we please focus on the big performance drains
in our system and the work that we have to do to get this new version
out to the people?

Hannes

Am 26.12.2009 14:58, schrieb dukeofgaming:
> FTR: The Kohana MVC framework asks for this as a requirement since PHP
> has had this enabled by default for quite some time.
>
> It would be nice that Joomla included an optional survey during the
> installation to find out this kind of stuff
>
> On Sat, Dec 26, 2009 at 5:37 AM, mic <michael...@gmail.com
> <mailto:michael...@gmail.com>> wrote:
>
> I am not shure what for this thread shall be good?
>
> Discussing some 'bad' practices?
> Performance boost (while a regular expresssion is sooo fast at all)?
> Breaking the compatibility?
> Making problems if the directive short_open_tag is DISabled (as it is
> on all of my servers)?
> Having/making troubles if XML will be used in conjuction with php?
>
> Really see no sense in this discussion - see also
> http://at2.php.net/manual/en/ini.core.php.
>
> And @Ruby: I do NOT see this technique at many develoepers (and I am
> happy about that!), but maybe you can highlight me/this - show me
> where in the core is this done (3PD is not from interest for me as
> there are too many lousy written scripts out there)?
>
>
> On Dec 25, 3:08 pm, Niels Braczek <nbrac...@bsds.de

> <mailto:nbrac...@bsds.de>> wrote:
> > Stian Didriksen schrieb:
> >
> > > @Niels, careful with using words like "only correct".
> >
> > I am...
> >
> > > As you forgot the fourth variation. When the php code are on
> just a
> > > single line, you don't need the semi-colon:
> > > <?php echo (some 1 line-php code here) ?>
> >
> > Yes, this form exists, but that was not the point. We're talking
> about
> > short open tags.
> >
> > Regards,
> > Niels
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

[Stian Didriksen]

I agree with Hannes.
The only exception I've seen to the rule are for the Nooku FW, that
use it only for template layouts, and have a fallback in case shortags
are turned off.
But that fallback does not apply for anything other than template
layouts.

@mic please know what you're talking about before critiquing. The
regular expressions are only applied when the server does not support
shortags. It's in the Nooku fw used for template layouts not for
performance reasons (there are other far more better areas to look at
in your code to improve that, like improving your queries, use caching
and more) it's mostly for code readability for the files that regular
users and more novice developers are most likely to make changes to
the code. Most people only want to modify the html output of the
extension a little bit, and in those files using shortags really makes
things a lot cleaner and simpler. And the regular expressions keeps
compatibility intact.

But if Joomla where to adopt this pattern from the Nooku FW. Now is
not a good time. It would require a lot of changes to the template
parsing code, and is something more suitable for 1.7 and 2.0.

I, like most devs, thinks the best thing to do for 1.6 now is to just
stick to the roadmap and don't let the feature creep take over :)

Cheers,
Stian Didriksen

[e-builds]

DOWN! Of course, I meant Nr.3 by Niels, in place of my faulty written
Nr.1!! How silly of me. I don't see a lot of Nr.1 by developers, but
Nr. 3!!!

[e-builds]

Joe, are you sure? Check the online php documentation (http://
be.php.net/manual/en/ini.core.php), reveals the following:

short_open_tag
Default : "1"
Changeable: PHP_INI_ALL
Changelog: PHP_INI_ALL in PHP <= 4.0.0. PHP_INI_PERDIR in PHP < 5.3.0

[e-builds]

dukeofgaming: IF there is some performance boost realted to this (if
someone confirms that is), I totally agree this to be put in the
survey.

[e-builds]

Ok thanks for your view, Hannes (and other people following up). That
is also what I was looking for, a view on how much performance this
would give (besides other arguments).

Kinf off topic, but:
What about the following as bigger performance boost (maybe still not
big enough for you, but I'll wager it).
I haven't had any reaction to it, but I do mean if we would use the
presented technique in that post on many other places.
http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/41c5a90404361045

[e-builds]

@mic, not that I am not a bit biased by now for my own idea, but some
answers, for the record:

> Performance boost (while a regular expresssion is sooo fast at all)?

I mean regular expression ON the code by a developer, not IN the code!

> Breaking the compatibility?
Which others then the ones you repeat here?

> Making problems if the directive short_open_tag is DISabled (as it is on all of my servers)?

Well, if performance would be relevant enough (which by now some say
it is negligable) and since the documentation of php says it's ENABLED
by default, I can only say: No pain, no gain.

> Having/making troubles if XML will be used in conjuction with php?

There is a very small workaround for this, and since there is much
less XML where it would be needed than all the 1001 places where
technique Nr.3 is used, this would be of no real importance. But
small, good point nevertheless. I did'tn pay attention to it before.

> Really see no sense in this discussion - see alsohttp://at2.php.net/manual/en/ini.core.php.

Am I missing something? It says "1" by default, which means ENABLED,
not?

> And @Ruby: I do NOT see this technique at many develoepers (and I am
> happy about that!), but maybe you can highlight me/this - show me
> where in the core is this done (3PD is not from interest for me as
> there are too many lousy written scripts out there)?

Sorry, my bad, see my previous answer about this (my faulty Nr.1
should actually be Nr. 3 by Niels)

[Joseph LeBlanc]

I stand corrected: the default in PHP 5.3.0 (which I'm running locally) is OFF, but the default for earlier versions is ON. Regardless, the current preferred setting for short_open_tag is OFF as this is the only way you can accommodate inline XML declarations. Adding <?xml version="1.0"?> to the top of a .php file will cause a parse error with short_open_tag ON.

-Joe

[Steven Pignataro]

Hannes,

You bring up an interesting point. Some people do not know the Joomla!
coding standards and it might be a good idea to point them in the
right direction for documentation on this so that they know the
Joomla! way.

Kindest regards,

--Steven Pignataro

[Mitch Pirtle]

On Sun, Dec 27, 2009 at 8:17 PM, Joseph LeBlanc <con...@jlleblanc.com> wrote:
> I stand corrected: the default in PHP 5.3.0 (which I'm running locally) is OFF, but the default for earlier versions is ON. Regardless, the current preferred setting for short_open_tag is OFF as this is the only way you can accommodate inline XML declarations. Adding <?xml version="1.0"?> to the top of a .php file will cause a parse error with short_open_tag ON.

+1 on that last sentence. Someone from Zend was explaining this to me
several years ago, and I managed to forget the reason, but remember
the sentiment (short tags are a bad idea in general). *blush*

This is a pretty big deal and is the primary argument for the
anti-shorttag folks.

-- Mitch

[dukeofgaming]

Just to clarify, I meant the kind of survey you get by submitting anonymously installation data, in this case, relevant stuff from php settings, php version, OS, etc.; not filling out anything manually but only enabling it as an option, IMO preferably off by default.

Portability is something that always matters and should prevail over the developers' comfort (sadly). PHP 5.3 has short open tags now disabled and this is the most interesting info I found on the matter:

http://stackoverflow.com/questions/1527719/php-denying-use-of-short-hand

http://www.mail-archive.com/inte...@lists.php.net/msg41868.html

Could not find official discussions about this, but saw mentioned somewhere. that remotion from PHP 6 is being discussed.

I like short open tags (and most probably keep using them) but my take on this is that it shouldn't be used for core, regardless of any performance gains (are these even big?, or just micro-optimizations?). PHP guys don't always make decissions that we like (such as the "\" for namespaces) so we should be already accustomed to this *shrug*.