 |
Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon. |
|
| View previous topic :: View next topic |
| Author |
Message |
Aryos
Smarty Rookie
Joined: 12 Jan 2010
Posts: 8
|
 Posted: Tue Jan 12, 2010 11:29 am Post subject: Memory usage in Smarty 3 |
 |
|
I have been doing lots of benchmarks in Smarty 3, including hundreds of files, on an application I'm developing. Due to the application not being yet released, I cannot post here much info; however, upon request, I could provide a few numbers, on some benchmarks. Benchmarks had to do with execution speed (uncompiled & compiled template files) and memory usage.
With the beta 6 release of Smarty 3, I'm glad to see that the execution times are down to the times of Smarty 2 (up to beta 5 I had up to 40% more in execution times).
However, the memory usage issue remains, as Smarty 3 seems to use up to 110% more memory, compared to Smarty 2. As the performance of a Web Application depends more on the RAM and CPU used (especially in shared hosting) rather than the execution time itself (pages on a Web server are not parsed linearly, one after another, but in parallel, meaning less CPU-RAM usage allows more pages/second to be delivered --faster execution time helps in the sense that when pages are faster, the RAM is freed faster and available for usage), the high memory usage has a negative impact much more than the positive impact of any faster execution times in Smarty 3.
I would be interested to know if this issue is known and if there are plans to optimize the memory handling. |
|
| Back to top |
|
mohrt
Administrator
Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA
|
| Posted: Tue Jan 12, 2010 3:38 pm Post subject: |
|
|
We are still working on optimizations. Smarty 3 makes extensive use of objects, and this is certainly the cause of the extra memory usage.
I think the biggest contributor to the issue are the assigned tpl variables. Currently each one is an object. Although this makes fine-grained control of the vars nice (ie. caching, filters, etc.), all these objects take their toll on memory and initialization. The next trial will be to revert these back to regular vars and test the impact. |
|
| Back to top |
|
Lemon Juice
Smarty Pro
Joined: 24 May 2006
Posts: 109
|
| Posted: Wed Jan 27, 2010 10:53 pm Post subject: |
|
|
| Why are most smarty object methods lazy-loaded? As far as I know invoking methods via __call is very slow compared to direct method access. Plus call_user_func_array and additional file access make it even slower. Why not put all the methods in the main class definition? PHP is lightning fast in parsing even large chunks of code if it is in a single file. |
|
| Back to top |
|
mohrt
Administrator
Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA
|
| Posted: Thu Jan 28, 2010 6:05 pm Post subject: |
|
|
| The common methods are in the object. There are some lesser-used methods that get lazy loaded, but for the most part they are part of the object, or part of the inherited object. We are still doing tests and benchmarks, figuring out what combinations offer the best for memory management and speed. |
|
| Back to top |
|
Lemon Juice
Smarty Pro
Joined: 24 May 2006
Posts: 109
|
| Posted: Sat Jan 30, 2010 12:45 pm Post subject: |
|
|
| mohrt wrote: | | There are some lesser-used methods that get lazy loaded, but for the most part they are part of the object, or part of the inherited object. |
As far as I can see there are 78 methods beginning with "smarty_method_" which are lazy loaded from separate files. True, they are not the most commonly used but in certain setups this may have some performance impact. For example, if I use a lot of custom modifiers and functions I like to put them all in a single file and then use register_modifier(), register_block(), etc. to speed things up by avoiding loading many separate files by compiled templates. Now with lazy loading of register_xxx methods the benefit of doing so could be dubious.
| mohrt wrote: | | We are still doing tests and benchmarks, figuring out what combinations offer the best for memory management and speed. |
Good to hear that! It's just that I have read a few reviews of the still unfinished beta releases and the tests indicated a considerable decrease in performance. I haven't tested it personally but I'm sure the final release will be better in this regard. However, in the past I have done some performance tests of the magic __call methods and they indicated clearly that invoking __call is 2-3 times slower than invoking a normal method and when you add the overhead of the code in the __call that has to process the method arguments and do all its magick to finally invoke the target method, the performance hit grows many times more.
| mohrt wrote: | | I think the biggest contributor to the issue are the assigned tpl variables. Currently each one is an object. Although this makes fine-grained control of the vars nice (ie. caching, filters, etc.), all these objects take their toll on memory and initialization. The next trial will be to revert these back to regular vars and test the impact. |
Just curious, what specific features would be lost if tpl variables were not objects? |
|
| Back to top |
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
