Another follow on to optimizations, I noticed that the framework make
some very minimal assumptions about what extensions are available, while
that's good for broad compatability it creates big performance worries.
One case in particular:
Zend_Json_Encode / Zend_Json_Decode.
With php now making json_encode() and json_decode() fairly standard the
performance hit of not calling these when available is quite substantial
-- in one application it was 1.3seconds of decode time vs. 0.02 seconds
for the builtin version.
It would be wise to have the appropriate internal checks to use
extensions when available...
--koblas
Stéphane Bisinger wrote:
Hi all,
I was wondering if the current code in the Core
section of the framework has been optimized in any
way. I know that this is yet a preview, but it is not
so far from version 1.0.0, so it could be the right
time to think about this kind of issues. I'm telling
you this because using ZF in a large application I
could find some bottlenecks in the framework itself:
for instance, if you load a medium sized ini file with
Zend_Config_Ini, the recursive function calls in the
constructor slows down the application quite a bit. In
particular, if there are a lot of extended sections
the recursion happens for two functions
(Zend_Config_Ini::_processExtends and
Zend_Config_Ini::_processKey ) slowing everything
down.
There are other similar issues around the code which
come up with a simple profiling and I think that
indeed some improvements should be made. What do you
think about it? Is the code mature enough to start
toying with optimizations?
If you feel the time is right, I might have a look
myself.
Best regards,
Stéphane
___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html
