|» Metadata||» Status|
Looking at open source applications/libraries, a lot of people complain about the bloat ness, amongst others the size byte-wise, of scripts.
Since I started using PHP in 2003 I'm asking myself, why is source code released only in one version? Should the best practice not be a two-way deployment? The goal being (1) Good Looking Code (TM), i.e. structured (one class per file, if the OOP path is followed ;-), well documented and throughout unit tested (2) compact fast running optimized code.
How can programmers be motivated and supported goal 1-wise, without the need to sacrifice goal 2?
One aspect of optimization is the direct juggling with byte code and/or with the source code. On the byte code level there are already several solutions available as well as for caching techniques. But what about the source code reorganization? AFAIK - please correct me, if I'm wrong - the (open source) contributions have been sparse so far.
The simple equation Execution Time = Loading Time + Parsing Time, which does not take into account the fact of external constraints like DB responsiveness etc., leads to the logical answer that the loading time (incl. the imports of every single file needed for execution) is where to kick off with the tweaking.
However, playing devil's advocate, one could argue that the ZEND Engine caches the requested scripts for future use and that the parser skips all comments. So where is the added value? Brainstorming, the following pros come into mind: reduced file size and the eventually "packaging" must have an impact on the memory footprint (even if minimal), the parsing of source code as well as the no. of file I/O operations to execute performance-wise, albeit PHP is very fast in this respect.
Here we go!
To Make One's Point
On a conceptual level the goal is to create a new file
Following the lines it makes sense to achieve either a one-to-one
Having sorted out the file types to create, the following strategies spring into mind:
What's the reasoning for this layered approach? The main idea is (1) to acknowledge possible coding rules set in place - e.g. only stripping off comments is allowed (2) to have the user becoming more confident about the tool, step by step. Does it really leave the code purpose untouched, when applying one strategy after the other?
So far so good. The Strategy Pattern is in place. But what about attaching additional responsibilities to a
The package contains two simple examples of
The third decorator
Please take notice of the following: Before chaining several decorators in one reorganization process, look out for any restriction/constraint information in the respective documentation usage-wise.
To get the big picture see the sketch.
Convert a script file and all included/required files to a single packed library file, to which an overriding header is added:
Now some figures:
If all relevant (well documented) 15 classes of the release 0.1.0 with a total size of 53,698 Bytes are packed into a single library, the reduction achieved is -81.35%, i.e. Library.phps is only 18.65% - 10,014 Bytes - of the size noted above. The header added during the reorganization process is still included in the result, see screoBuild.phps and screoLibrary.phps.
To check the correctness of the figures stated above, the import statements in
For more examples see the unit tests in the PEAR Package File.
P.S.: To run the unit tests
The package works correctly only with, for the time being, "pure" PHP script files. "Mixed" PHP code will be addressed in the near future.
It is curcial to throughout test (not only unit test) the code after optimizing it with this package and before building a release to deploy.
Suggested pack practice to follow:
P.S.: Currently I'm having food for thought regarding the FaÃ§ade/Factory Pattern I would like to implement, to further simplify the package interface as well as regarding the front-end script/batch file for the stand-alone use.
But most importantly, this package promotes the best practice of a two-way deployment and complies with the basic requirement to create a PEAR library/tool, for adding value to already existing optimization/performance enhancing applications.
|» Dependencies||» Links|
|» Timeline||» Changelog|