Re: [SMARTY-DEV] more abstraction committed

On Thu, May 08, 2003 at 03:34:52PM -0500, Monte Ohrt wrote: > I committed some more (fairly major) changes. > > So far, the following private functions have been removed from > Smarty.class.php and into their own plugin core files: > > core.assign_smarty_interface.php > core.compile_template.php > core.create_dir_structure.php > core.display_debug_console.php > core.fetch_template_info.php > core.get_include_path.php > core.get_microtime.php > core.get_php_resource.php > core.is_secure.php > core.is_trusted.php > core.load_plugins.php > core.load_resource_plugin.php > core.parse_file_path.php > core.process_cached_inserts.php > core.read_cache_file.php > core.rm_auto.php > core.rmdir.php > core.run_insert_handler.php > core.smarty_include.php > core.smarty_include_php.php > core.write_cache_file.php > core.write_compiled_template.php > > This has reduced the size of Smarty.class.php from 88K down to 52K. > There is still quite a bit more that can be abstracted, but this is a > good start. > > I tried a simple benchmark to see how it responds. This is a simple > "hello world" template with one config_load call: > > commmand_line: > 2.5.0: 1.08s > cvs: 0.73s > > apache with PHPA: > 2.5.0: 0.122s > cvs: 0.120s > > apache-gzip with PHPA: > 2.5.0: 0.036s > cvs: 0.035s > > As you can see, the gains from command line execution are quite nice, > but with PHPA the gains are almost negligible, but at least they are not > any slower so this abstration is not causing any performance drop! the numbers read great! > I mostly abstracted things used during the compile phase. The other > things (like filepath rendering) I left to keep optimum speed. (I think > the filepath rendering should be cached instead of computed on each page > call. That's another project :-) you mean in _get_plugin_filepath() ? i thought about this also. the is_readable()s are cached by php anyway but it's worth a test, if this can be speeded up. > My goal is to abstract everything that can be done so without a > performance penalty. I think all of the compiler functions could be > broke down to this too, maybe getting rid of Smarty_Compiler.class.php > altogether. hmm, i have to think about this. maybe i need another beer and some sleep to get on this :) it sounds revolutionaty, but not in the rotating sense ;-) > Anyways, a LOT has changed here so bugs may be present. I tried to test > as good as I could, but please help! no problem. i have cvs-checkouts of some real-live projects compatible to 2.5.0 and post. nothing ultra-fancy, but decent smoke-tests. > FYI, I'm off to Las Vegas for one week starting tomorrow, so I won't be > too responsive until the 19th. > > Let me know what you all think of this direction for Smarty. i must admit i am a bit sheepish about breaking smarty down to so many files, i think every stat/include adds overhead, but i love to let the numbers speek for themselves. maybe there is some benefit in a third parameter to _execute_core_function(): $subject, or $group then files would be located by subject and not only by core-function-name, so we don't need a file for each sub-aspect. but i think i have to bechmark and compare such an approach. anyway: i'll do some testing of your latest commits soon. if las vegas is regarded as some kind of holiday have fun, if otherwise have success :) greetings messju > Monte