include.php File Reference
Go to the source code of this file.
|
Enumerations |
| enum | SPUNQ_ROOT_FOLDER |
Variables |
| | $mapping |
| | Contains mappings of class names to file names.
|
Detailed Description
- Developer log entry:
- Necdet Can Atesman (2009-02-18): About performance: including all files one by one was causing performance issues. Creating a single include file containing all the source of the spunQ framework and using several optimization algorithms on that file (stripping comments, reducing unnecessary whitespace, etc.) improved the startup a bit. It went down from 0.032s on my box to 0.024s. That's quite ok.
Running the framework in debug/deployment mode could be reasonable, where the second mode could make use of such caching. The only real drawback is that the include file cannot react to modifications of the source files of the framework.
- Developer log entry:
- Necdet Can Atesman (2009-03-11): Reading the lines above I just noticed that reacting to file changes is possible anyway. The code for that would be in a seperate file, so it could be decided which include method to use.
- Developer log entry:
- Necdet Can Atesman (2009-04-07): Did some more tests and had these results:
- No modification (include file including all other files):
- inclusion: ~48 ms
- initialization: ~27 ms
- connecting to db: ~3 ms
- Retrieving an object: ~21 ms
- Total execution time: ~100 ms
- Compressed include file (All source code in single file, removed as much white space as possible, removed all unneeded doc comments, removed all normal comments):
- inclusion: ~25 ms
- initialization: ~27 ms
- connecting to db: ~3 ms
- Retrieving an object: ~21 ms
- Total execution time: ~77 ms
- Removing all calls to debug() and vdebug():
- inclusion: ~25 ms
- initialization: ~27 ms
- connecting to db: ~3 ms
- Retrieving an object: ~8 ms
- Total execution time: ~64 ms
This concludes the benchmarking for now. I would say that the inclusion time is acceptable for now - even if it can be cut in half. The debug/deployment modes are still an option but not needed yet. What is more important is that execution time went up almost by a factor of 3, as the debug calls were removed. This is obviously not an option during development - as well as the first few months the framework is in use.
Furthermore, the analysis of the startup showed that the bottleneck is still the recursive inclusion of source files - although this had been adjusted a bit with caching.
Summary of expensive operations (in order of magnitude):
- Initializing framework (50%)
- Including modules source code recursively in Type::init() (30%)
- other stuff done in Type::_init() (10%)
- RemotePeerConnection::_init() (5%)
- Language::_init() (3%)
- Including framework source code (20%)
- Database interaction (13%)
- Creating DataObjects (13%)
Many of these problems could be solved by the imminent redesign of certain parts.
- Developer log entry:
- Necdet Can Atesman (2009-06-25): Just a note: Many of the metrics in the devlogs of this file are deprecated. The new include system (using the file names) has improved performance, for example. The inclusion of the files are done centrally, the core files have a direct mapping, etc, etc.
Definition in file include.php.
Variable Documentation
