John,
Thanks for the great feedback. See below:
> -----Original Message-----
> > >2) MOD_PHP - install PHP as an Apache module instead of running
> it as a CGI
> >process. This should speed you up quite a bit. I am still trying
> to find a
> >good host who runs PHP as an Apache module. Most that I have
> spoken to only
>
> Not should, but does, significantly. Since I'm a reseller, I
> won't mention names. Find a good host, with good tech. support.
>
This brings up another question of mine. Does anyone have experience with
the Zend Optimizer? What kind of speed improvements can be expected? Any
downsides?
> >3) Removed unneeded comments. Comments in compiled languages (like C++,
>
> I have to disagree here, not on technical merits, but on
> principle. Yes, PHP will have to read the comments (a file
> read), but is quite able at discarding them.
Well, most folks seem to think the extra comments are no big deal. So, I'll
defer to the voice of wisdom.
Better parsing from
> using double-quotes ONLY where necessary will actually be a
> bigger speedup. You would be surprised at the time difference in
> parsing "This string" vs. 'This string' (in an overall system
> deployment, not just this one string). The difference being no
> checking for variable substitution. Personally, I think it works
> well with html also, and easier to read without the escaping of
> quotes all of the time.
>
This is a great tip. It is not even mentioned on the PHP site (that I could
find).
In fact, both the print and echo examples in the PHP net manual all use
double-quotes. Weird.
> There is also a speedup in echo vs. print. Run many iterations
> over the following and test for yourself in your environment
> (PHP3 or PHP4 doesn't matter although PHP4 is nice :)
>
> print "This is $mystring and \"this\" is some html<br>\n";
> vs echo 'This is '. $mystring. ' and "this" is some html<br>'. '\n';
> // why waste the newline character :)
>
Any idea why echo would be quicker than print? It is not due to the fact
that you are using single-quotes?
> >4) The Language and ScreenInfo files: it seems a waste to read
> in the whole
> >of these files and define a gazillion variables that we probably do not
>
> Parsing the switch will take longer. More variables aren't
> really that big of an issue, especially in PHP4. Although
> encapsulating them within classes is a GoodIdea in my opinion.
> It does sound like Leon has done quite a bit of work seperating
> in v2, but I haven't looked at it yet. I also feel that any
> further work really should be done against the new version - if
> it ain't broke, don't fix it (to a large extent).
>
The switch idea was just a quick thought. I'll give this some more thought.
I agree that any improvements should be made to FT 2 and not 1.
> >7) CSS - I think we should keep the Stylesheet file but we should not
> >include it in everypage. We should use it as an external
> stylesheet. We can
>
> If external it is cached. Why not include it in every page
> then? The few bytes for the line to be read? OS's are quite
> good at reading files. I think having one place to change the
> look is another GoodThing.
>
Not sure I understand your point. I agree that we should have only one place
for style elements.
I just think that instead of doing an INCLUDE, we should change the HEAD
section to use something like:
<LINK REL="stylesheet" HREF="/ourstyle.css" TYPE="text/css">
There's really no point in sending the same info over and over to the client
if we don't have to, IMHO.
Leon, if you are reading this, what do you think of integrating some the
ideas into FT 2?
Are you using single-quotes in FT2? If not, I suggest we divide up the
modules and each do some editing.
I'd also like to get more ideas on the variables issue (or non-issue?). Any
elegant solutions?
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
