Before I respond, recall the first principle of optimization. You should
always
measure performance first and concentrate your efforts on the slowest parts
first. You also should concentrate on those parts that are executed
frequently.
(eg, no sense in optimizing a code segment that's executed once a month).
Also, consider that faster hardware is really cheap compared to faster
programmers. Anyone remember my hierarchy of goals for any project?
This is a quote from a post of about a year ago:
> The first principle to consider when making changes to the system is
whether
> the change fits the spirit of the application. The second principle to
> consider is whether it makes it easier to work on the system. After the
> first two principles, then you can ask about other considerations such as
> increasing run-time performance.
Micheal Wrote:
> 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
> run it as a CGI process. Can any one help here? Also, if you run PHP as
an
> Apache module - could this crash the server if there is a problem with
PHP?
> Is this why hosts are reluctant to do this?
Check out he.net. My site is host there. I wouldn't recommend running FT
using a CGI version if you get any significant traffic.
> 3) Removed unneeded comments. Comments in compiled languages (like C++,
> Java) are removed during compilation. So, you could write a book in the
> comments field and it would not adversely affect the size/speed of the OBJ
> or EXE. However, PHP is a parsed language. Every comment line is one more
> line that the parser have to read. We should remove comments which do not
> add to the readability of the code. In my opinion, the comment blocks at
the
> top should be cut down. I have removed everything except the copyright,
name
> of file, and version number. If you add up all the comments from all the
> include files, it can be quite a lot of extra lines.
Have you actually tested the effect on performance? The parser is really,
really
fast, so comments shouldn't have much of an effect.
> 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
> need. Is there a way of changing this? For FT 1.x? I was thinking of
> something simple like a SWITCH statement allowing us to only define the
vars
> we need for the particular screen we are building. Any other ideas? Is
this
> a big issue?
It's an important issue, but I'm not sure a switch statement helps. Here's
the
idea behind the design:
You need screen information before you actually display the screen because
you need the title tag, the layout modules, etc. You also want the screen
modules to to be flat HTML that anyone can edit if necessary. (This won't
be true for the dynamic shopping pages, but consider all the flat pages that
a site could have too).
One direction we could go is to make a separate ScreenInfo module for
each screen. That would certainly reduce the memory used, but consider
the huge number of files you'd generate. I'm not sure the maintenance cost
is worth the tiny performance gain, but I hesitate to dismiss it without
testing
first.
The language stuff is a similar situation. From a programming perspective,
it's nice to have all that data in one spot. That's the idea of cohesion,
right?
> 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
> change the code to reference the file in the IMAGES_DIR (or where ever).
The
> benefit: The way it is currently done: the same stylesheet info has to be
> passed over the wire with every request. With an external stylesheet, the
> stylesheet file is downloaded to the browser's cache and used from the
> client. Therefore, it is only passed over the wire ONCE. Stylesheets are
not
> that big, but all the little things add up.
Yeah, we should switch to using a linked stylesheet. It should be
structured
like index.php, though, in case you need to do cloaking. (eg font-size: 10
for Mac,
font-size: 12 for Windows).
Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
