ZF2 speed

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ZF2 speed

Tomáš Fejfar
We do ZF meetups in Prague every month, where we try to help czech ZF developers to stay in touch with the latest changes in ZF2. For one of the latest we created a simple blog application (admin, articles, comments, edpUser). It's really simple app, that creates model, connects to DB, fetches some results and thats it. 

It takes around 250ms per request (i3, SDD). That is not bad, but it's more than one would expect from such a simple app. Keeping in mind the fact, that speed was one of the crucial requirements for ZF2, I'd like to brign this issue back to light. As I see more and more layers of abstraction being added to the framework, the question rises whether the flexibility is not killing the speed yet again. 

I unfortunatelly don't have time (at least till early summer) to play much with the latest betas. Just following ML and discussions takes a lot of time, so I can't take this for myself. 

So the question is: Is anyone checking this? I think Rob Allen's getting started tutorial would be ideal candidate for speed measurements. It has version for every beta and also for ZF1 versions, so it can track performance changes. 

I know that the speed can be improved by caching something here and there, but the baseline performance of the framework is important too. 

Tomas Fejfar 
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Marco Pivetta
This post has NOT been accepted by the mailing list yet.
Hi there!
Most of the processing time usually comes from runtime definition generated by Zend\Di.
This is well known and makes ZF2 around 3 times slower than ZF1 for now.
From what I know this has been delayed to even after beta4...
Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 23 February 2012 19:44, Tomáš Fejfar [via Zend Framework Community] <[hidden email]> wrote:
We do ZF meetups in Prague every month, where we try to help czech ZF developers to stay in touch with the latest changes in ZF2. For one of the latest we created a simple blog application (admin, articles, comments, edpUser). It's really simple app, that creates model, connects to DB, fetches some results and thats it. 

It takes around 250ms per request (i3, SDD). That is not bad, but it's more than one would expect from such a simple app. Keeping in mind the fact, that speed was one of the crucial requirements for ZF2, I'd like to brign this issue back to light. As I see more and more layers of abstraction being added to the framework, the question rises whether the flexibility is not killing the speed yet again. 

I unfortunatelly don't have time (at least till early summer) to play much with the latest betas. Just following ML and discussions takes a lot of time, so I can't take this for myself. 

So the question is: Is anyone checking this? I think Rob Allen's getting started tutorial would be ideal candidate for speed measurements. It has version for every beta and also for ZF1 versions, so it can track performance changes. 

I know that the speed can be improved by caching something here and there, but the baseline performance of the framework is important too. 

Tomas Fejfar 



If you reply to this email, your message will be added to the discussion below:
http://zend-framework-community.634137.n4.nabble.com/ZF2-speed-tp4414795p4414795.html
To start a new topic under ZF Contributor, email [hidden email]
To unsubscribe from ZF Contributor, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

SpiffyJr
In reply to this post by Tomáš Fejfar
There's a lot left to do - namely compiled DI definitions. That should help a LOT.

Kyle S
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare



2012/2/23 Tomáš Fejfar <[hidden email]>
We do ZF meetups in Prague every month, where we try to help czech ZF developers to stay in touch with the latest changes in ZF2. For one of the latest we created a simple blog application (admin, articles, comments, edpUser). It's really simple app, that creates model, connects to DB, fetches some results and thats it. 

It takes around 250ms per request (i3, SDD). That is not bad, but it's more than one would expect from such a simple app. Keeping in mind the fact, that speed was one of the crucial requirements for ZF2, I'd like to brign this issue back to light. As I see more and more layers of abstraction being added to the framework, the question rises whether the flexibility is not killing the speed yet again. 

I unfortunatelly don't have time (at least till early summer) to play much with the latest betas. Just following ML and discussions takes a lot of time, so I can't take this for myself. 

So the question is: Is anyone checking this? I think Rob Allen's getting started tutorial would be ideal candidate for speed measurements. It has version for every beta and also for ZF1 versions, so it can track performance changes. 

I know that the speed can be improved by caching something here and there, but the baseline performance of the framework is important too. 

Tomas Fejfar 

Kyle S
blogs @ www.spiffyjr.me
github @ www.github.com/spiffyjr
follow @ www.twitter.com/spiffyjr
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Sascha-Oliver Prolic
In a production environment you should use service locators, these can
be generated by zend\di. this will improve the performance much more
than only di definitions. the instantiation of objects through zend\di
takes a lot of time currently. The service locator generator was
broken the last time i tried to play with it, but i guess Ralph will
fix it soon (when not already done). ;-)

@Tomáš Fejfar: You can enable xdebug profiler and analyse the
bottlenecks quickly with kcachegrind (linux tool) or phpstorm (nice
web ide). Would be interessting, if you found other bottlenecks.

Regards

Sascha-Oliver Prolic

2012/2/23 Kyle S <[hidden email]>:

> There's a lot left to do - namely compiled DI definitions. That should help
> a LOT.
>
> Kyle S
> Blog | GitHub | Twitter
>
> "There is a tide in the affairs of men. Which, taken at the flood, leads on
> to fortune; Omitted, all the voyage of their life Is bound in shallows and
> in miseries." - WIlliam Shakespeare
>
>
>
> 2012/2/23 Tomáš Fejfar <[hidden email]>
>>
>> We do ZF meetups in Prague every month, where we try to help czech ZF
>> developers to stay in touch with the latest changes in ZF2. For one of the
>> latest we created a simple blog application (admin, articles, comments,
>> edpUser). It's really simple app, that creates model, connects to DB,
>> fetches some results and thats it.
>>
>> It takes around 250ms per request (i3, SDD). That is not bad, but it's
>> more than one would expect from such a simple app. Keeping in mind the fact,
>> that speed was one of the crucial requirements for ZF2, I'd like to brign
>> this issue back to light. As I see more and more layers of abstraction being
>> added to the framework, the question rises whether the flexibility is not
>> killing the speed yet again.
>>
>> I unfortunatelly don't have time (at least till early summer) to play much
>> with the latest betas. Just following ML and discussions takes a lot of
>> time, so I can't take this for myself.
>>
>> So the question is: Is anyone checking this? I think Rob Allen's getting
>> started tutorial would be ideal candidate for speed measurements. It has
>> version for every beta and also for ZF1 versions, so it can track
>> performance changes.
>>
>> I know that the speed can be improved by caching something here and there,
>> but the baseline performance of the framework is important too.
>>
>> Tomas Fejfar
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

David Muir-2
WebGrind is also a handy tool as it's cross platform, and only needs a
browser :-)

David

On 24/02/12 07:23, Sascha-Oliver Prolic wrote:

> In a production environment you should use service locators, these can
> be generated by zend\di. this will improve the performance much more
> than only di definitions. the instantiation of objects through zend\di
> takes a lot of time currently. The service locator generator was
> broken the last time i tried to play with it, but i guess Ralph will
> fix it soon (when not already done). ;-)
>
> @Tomáš Fejfar: You can enable xdebug profiler and analyse the
> bottlenecks quickly with kcachegrind (linux tool) or phpstorm (nice
> web ide). Would be interessting, if you found other bottlenecks.
>
> Regards
>
> Sascha-Oliver Prolic
>
> 2012/2/23 Kyle S <[hidden email]>:
>> There's a lot left to do - namely compiled DI definitions. That should help
>> a LOT.
>>
>> Kyle S
>> Blog | GitHub | Twitter
>>
>> "There is a tide in the affairs of men. Which, taken at the flood, leads on
>> to fortune; Omitted, all the voyage of their life Is bound in shallows and
>> in miseries." - WIlliam Shakespeare
>>
>>
>>
>> 2012/2/23 Tomáš Fejfar <[hidden email]>
>>> We do ZF meetups in Prague every month, where we try to help czech ZF
>>> developers to stay in touch with the latest changes in ZF2. For one of the
>>> latest we created a simple blog application (admin, articles, comments,
>>> edpUser). It's really simple app, that creates model, connects to DB,
>>> fetches some results and thats it.
>>>
>>> It takes around 250ms per request (i3, SDD). That is not bad, but it's
>>> more than one would expect from such a simple app. Keeping in mind the fact,
>>> that speed was one of the crucial requirements for ZF2, I'd like to brign
>>> this issue back to light. As I see more and more layers of abstraction being
>>> added to the framework, the question rises whether the flexibility is not
>>> killing the speed yet again.
>>>
>>> I unfortunatelly don't have time (at least till early summer) to play much
>>> with the latest betas. Just following ML and discussions takes a lot of
>>> time, so I can't take this for myself.
>>>
>>> So the question is: Is anyone checking this? I think Rob Allen's getting
>>> started tutorial would be ideal candidate for speed measurements. It has
>>> version for every beta and also for ZF1 versions, so it can track
>>> performance changes.
>>>
>>> I know that the speed can be improved by caching something here and there,
>>> but the baseline performance of the framework is important too.
>>>
>>> Tomas Fejfar
>>

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

EvanDotPro
In reply to this post by Tomáš Fejfar
2012/2/23 Tomáš Fejfar <[hidden email]>
We do ZF meetups in Prague every month, where we try to help czech ZF developers to stay in touch with the latest changes in ZF2. For one of the latest we created a simple blog application (admin, articles, comments, edpUser). It's really simple app, that creates model, connects to DB, fetches some results and thats it. 

Is this application somewhere we can see it? Also EdpUser is now ZfcUser ;).
 
It takes around 250ms per request (i3, SDD). That is not bad, but it's more than one would expect from such a simple app. Keeping in mind the fact, that speed was one of the crucial requirements for ZF2, I'd like to brign this issue back to light. As I see more and more layers of abstraction being added to the framework, the question rises whether the flexibility is not killing the speed yet again. 

I unfortunatelly don't have time (at least till early summer) to play much with the latest betas. Just following ML and discussions takes a lot of time, so I can't take this for myself. 

So the question is: Is anyone checking this? I think Rob Allen's getting started tutorial would be ideal candidate for speed measurements. It has version for every beta and also for ZF1 versions, so it can track performance changes. 

I have been keeping an eye on this and right now the biggest percentage of execution time seems to be tied up in autoloading. If you enable APC and my EdpSuperluminal module to eliminate most of the autoloading overhead, you're left with only a few main places to optimize. The primary pain point being runtime DI definitions, which like Kyle said, will be replaced with compiled definitions in production.
 
I know that the speed can be improved by caching something here and there, but the baseline performance of the framework is important too. 

I'm very interested in bootsting the baseline performance, but in my last audit (using xhprof and xdebug+webgrind) I came up mostly dry on places we could optimize to make a big difference. There are a few tiny micro-opts here and there that I identified, but overall, there's nothing besides runtime DI definitions and autoloading that is taking up a majority of the execution time...

If you or anyone else are able to find anything that could make a difference I am all ears!

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Artur Bodera
In reply to this post by Tomáš Fejfar
2012/2/23 Tomáš Fejfar <[hidden email]>
We do ZF meetups in Prague every month, where we try to help czech ZF developers to stay in touch with the latest changes in ZF2. For one of the latest we created a simple blog application (admin, articles, comments, edpUser). It's really simple app, that creates model, connects to DB, fetches some results and thats it. 

It takes around 250ms per request (i3, SDD). That is not bad, but it's more than one would expect from such a simple app. Keeping in mind the fact, that speed was one of the crucial requirements for ZF2, I'd like to brign this issue back to light. As I see more and more layers of abstraction being added to the framework, the question rises whether the flexibility is not killing the speed yet again. 


Are those benchmarks with or without opcode cache?

From my experience classmaps are super-slow without it, because PHP loads those classmap php's with huge arrays inside. Once APC is loaded, classmaps are fetched directly from cache and it results in much better autoload performance as compared to SPL-0 autoloaders.

Also - what Evan said ;)


-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




 
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Tomáš Fejfar
I seems I'm not the only one to see the speed as a problem. 


Our app was runing on basic XAMPP with zend_optimizer enabled. Maybe phpinfo() later. 


2012/2/23 Artur Bodera <[hidden email]>
2012/2/23 Tomáš Fejfar <[hidden email]>
We do ZF meetups in Prague every month, where we try to help czech ZF developers to stay in touch with the latest changes in ZF2. For one of the latest we created a simple blog application (admin, articles, comments, edpUser). It's really simple app, that creates model, connects to DB, fetches some results and thats it. 

It takes around 250ms per request (i3, SDD). That is not bad, but it's more than one would expect from such a simple app. Keeping in mind the fact, that speed was one of the crucial requirements for ZF2, I'd like to brign this issue back to light. As I see more and more layers of abstraction being added to the framework, the question rises whether the flexibility is not killing the speed yet again. 


Are those benchmarks with or without opcode cache?

From my experience classmaps are super-slow without it, because PHP loads those classmap php's with huge arrays inside. Once APC is loaded, classmaps are fetched directly from cache and it results in much better autoload performance as compared to SPL-0 autoloaders.

Also - what Evan said ;)


-- 
      __
     /.)\   <a href="tel:%2B48%20695%20600%20936" value="+48695600936" target="_blank">+48 695 600 936
     \(./   [hidden email]




 

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Tomáš Fejfar
BTW the app is here https://github.com/mhujer/4iz228-semestralka

2012/2/24 Tomáš Fejfar <[hidden email]>
I seems I'm not the only one to see the speed as a problem. 


Our app was runing on basic XAMPP with zend_optimizer enabled. Maybe phpinfo() later. 


2012/2/23 Artur Bodera <[hidden email]>
2012/2/23 Tomáš Fejfar <[hidden email]>
We do ZF meetups in Prague every month, where we try to help czech ZF developers to stay in touch with the latest changes in ZF2. For one of the latest we created a simple blog application (admin, articles, comments, edpUser). It's really simple app, that creates model, connects to DB, fetches some results and thats it. 

It takes around 250ms per request (i3, SDD). That is not bad, but it's more than one would expect from such a simple app. Keeping in mind the fact, that speed was one of the crucial requirements for ZF2, I'd like to brign this issue back to light. As I see more and more layers of abstraction being added to the framework, the question rises whether the flexibility is not killing the speed yet again. 


Are those benchmarks with or without opcode cache?

From my experience classmaps are super-slow without it, because PHP loads those classmap php's with huge arrays inside. Once APC is loaded, classmaps are fetched directly from cache and it results in much better autoload performance as compared to SPL-0 autoloaders.

Also - what Evan said ;)


-- 
      __
     /.)\   <a href="tel:%2B48%20695%20600%20936" value="+48695600936" target="_blank">+48 695 600 936
     \(./   [hidden email]




 


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

EvanDotPro
In reply to this post by Tomáš Fejfar
2012/2/23 Tomáš Fejfar <[hidden email]>
I seems I'm not the only one to see the speed as a problem. 


Enrise is a great company and the author of that article did his homework before publishing those results. To quote the end of that article:

So, can we conclude that ZF2’s performance sucks? No, definitely not.
Don’t forget it’s still in beta and I’m using a standard skeleton without any optimizations like caching and class map autoloading. And in this respect ZF2 has much more to offer than ZF1.

Before publishing I’ve discussed the results of this benchmark on freenode.net/#zftalk.2 to find out what the problem could be. Matthew Weier O’Phinney pointed out that the bulk of program execution right now is in the DI container. They know how to address this, but have lowered its priority in favor of finishing features needed.

Matthew said; “I’d also argue it’s premature to report benchmarks at this point. We’re well aware of issues currently, but plan to address them pre-stable release” And he’s completely right. This benchmark was meant purely to see if the article from piprime.fr made any sense. And it’s a starting point for me to see what you can do with the different optimizations and what their performance impact is.

There will be a follow-up to this article, hopefully with the conclusion that, with all possible optimizations correctly configured, ZF2 will kick ZF1′s ass!

It can be concluded that this benchmark simply mirrors what we've already mentioned: autoloading and runtime DI definitions make up a bulk of the request time.

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

EvanDotPro
For the interested, here's the top 99 (100 excluding main()) methods sorted by exclusive execution time:


The list is generated using xhprof with the latest skeleton + EdpSuperluminal + APC to eliminate noise from autoloading time. Looking at the first sheet, you'll notice it's mostly DI runtime definition related stuff. 

On the second sheet of that spreadsheet is the same benchmark ran without using Zend\Di. I replaced it with my own drop-in replacement class: https://gist.github.com/1896972. Once you take away autoloading and Zend\Di, there are very few things that stand out as performance culprits (though that call to date() that takes 8% of the runtime, 3.5ms, does seem a bit strange). 

TL;DR: With Zend\Di, the total execution time was around 210ms. Bypassing Zend\Di, the total execution time was around 42ms.

Anyway -- this data mostly validates my opinion that most of the optimization efforts really need to be focused on Zend\Di before anything else and it is my understanding that compiled DI definitions will help quite a bit with this.

Hope this clarifies any lingering questions about ZF2 performance.

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Ben Scholzen 'DASPRiD'
In reply to this post by Tomáš Fejfar
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

akrabat

On 24 Feb 2012, at 03:30, Ben Scholzen wrote:
>
> Zend Optimizer is not an opcode cache tho (very bad product naming,
> @Zend). Try running with APC.

However, Zend Optimizer+ *is*  :)


Regards,

Rob...

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Sascha-Oliver Prolic
In reply to this post by EvanDotPro
Hi Evan,

thanks for the docs. One thing i saw is the massive usage of
array_key_exists, so i want to ask, whether we could  remove them in
favor of isset.
I published a small benchmark at https://gist.github.com/1900978.
isset is 4-5 times faster than array_key_exists and i don't see the
extra benefit in the usage of that function.

Regards

Sascha-Oliver Prolic

2012/2/24 Evan Coury <[hidden email]>:

> For the interested, here's the top 99 (100 excluding main()) methods sorted
> by exclusive execution time:
>
> https://docs.google.com/spreadsheet/ccc?key=0AqfVpJyG6BjsdFBGSk1jdDQ3ZEFDcTVFVTg4Mjk1WGc
>
> The list is generated using xhprof with the latest skeleton +
> EdpSuperluminal + APC to eliminate noise from autoloading time. Looking at
> the first sheet, you'll notice it's mostly DI runtime definition related
> stuff.
>
> On the second sheet of that spreadsheet is the same benchmark ran without
> using Zend\Di. I replaced it with my own drop-in replacement
> class: https://gist.github.com/1896972. Once you take away autoloading and
> Zend\Di, there are very few things that stand out as performance culprits
> (though that call to date() that takes 8% of the runtime, 3.5ms, does seem a
> bit strange).
>
> TL;DR: With Zend\Di, the total execution time was around 210ms. Bypassing
> Zend\Di, the total execution time was around 42ms.
>
> Anyway -- this data mostly validates my opinion that most of the
> optimization efforts really need to be focused on Zend\Di before anything
> else and it is my understanding that compiled DI definitions will help quite
> a bit with this.
>
> Hope this clarifies any lingering questions about ZF2 performance.
>
> --
> Evan Coury



--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Pádraic Brady
Hi Sascha,

The problem is that isset() will return false when the array key
exists but its value is set to null so there are a lot of use cases
where isset() couldn't be applied.

Paddy

On Fri, Feb 24, 2012 at 1:37 PM, Sascha-Oliver Prolic
<[hidden email]> wrote:

> Hi Evan,
>
> thanks for the docs. One thing i saw is the massive usage of
> array_key_exists, so i want to ask, whether we could  remove them in
> favor of isset.
> I published a small benchmark at https://gist.github.com/1900978.
> isset is 4-5 times faster than array_key_exists and i don't see the
> extra benefit in the usage of that function.
>
> Regards
>
> Sascha-Oliver Prolic
>
> 2012/2/24 Evan Coury <[hidden email]>:
>> For the interested, here's the top 99 (100 excluding main()) methods sorted
>> by exclusive execution time:
>>
>> https://docs.google.com/spreadsheet/ccc?key=0AqfVpJyG6BjsdFBGSk1jdDQ3ZEFDcTVFVTg4Mjk1WGc
>>
>> The list is generated using xhprof with the latest skeleton +
>> EdpSuperluminal + APC to eliminate noise from autoloading time. Looking at
>> the first sheet, you'll notice it's mostly DI runtime definition related
>> stuff.
>>
>> On the second sheet of that spreadsheet is the same benchmark ran without
>> using Zend\Di. I replaced it with my own drop-in replacement
>> class: https://gist.github.com/1896972. Once you take away autoloading and
>> Zend\Di, there are very few things that stand out as performance culprits
>> (though that call to date() that takes 8% of the runtime, 3.5ms, does seem a
>> bit strange).
>>
>> TL;DR: With Zend\Di, the total execution time was around 210ms. Bypassing
>> Zend\Di, the total execution time was around 42ms.
>>
>> Anyway -- this data mostly validates my opinion that most of the
>> optimization efforts really need to be focused on Zend\Di before anything
>> else and it is my understanding that compiled DI definitions will help quite
>> a bit with this.
>>
>> Hope this clarifies any lingering questions about ZF2 performance.
>>
>> --
>> Evan Coury
>
>
>
> --
> Sascha-Oliver Prolic



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Reply | Threaded
Open this post in threaded view
|

AW: [zf-contributors] ZF2 speed

Dennis Lassiter
In reply to this post by Sascha-Oliver Prolic
Hi Sascha,

array_key_exists and isset work differently. Isset also returns false if the value is null:

<?php

$array = array('foo' => 'bar', 'lorem' => 'ipsum', 'somethingelse' => null);

array_key_exists('foo', $array); // true
array_key_exists('lorem', $array); // true
array_key_exists('somethingelse', $array); // true

isset($array['foo']); // true
isset($array['lorem']); // true
isset($array['somethingelse']); // false

?>

Cheers,

Dennis Lassiter

-----Ursprüngliche Nachricht-----
Von: Sascha-Oliver Prolic [mailto:[hidden email]]
Gesendet: Freitag, 24. Februar 2012 14:37
An: Evan Coury
Cc: <[hidden email]>
Betreff: Re: [zf-contributors] ZF2 speed

Hi Evan,

thanks for the docs. One thing i saw is the massive usage of array_key_exists, so i want to ask, whether we could  remove them in favor of isset.
I published a small benchmark at https://gist.github.com/1900978.
isset is 4-5 times faster than array_key_exists and i don't see the extra benefit in the usage of that function.

Regards

Sascha-Oliver Prolic

2012/2/24 Evan Coury <[hidden email]>:

> For the interested, here's the top 99 (100 excluding main()) methods
> sorted by exclusive execution time:
>
> https://docs.google.com/spreadsheet/ccc?key=0AqfVpJyG6BjsdFBGSk1jdDQ3Z
> EFDcTVFVTg4Mjk1WGc
>
> The list is generated using xhprof with the latest skeleton +
> EdpSuperluminal + APC to eliminate noise from autoloading time.
> Looking at the first sheet, you'll notice it's mostly DI runtime
> definition related stuff.
>
> On the second sheet of that spreadsheet is the same benchmark ran
> without using Zend\Di. I replaced it with my own drop-in replacement
> class: https://gist.github.com/1896972. Once you take away autoloading
> and Zend\Di, there are very few things that stand out as performance
> culprits (though that call to date() that takes 8% of the runtime,
> 3.5ms, does seem a bit strange).
>
> TL;DR: With Zend\Di, the total execution time was around 210ms.
> Bypassing Zend\Di, the total execution time was around 42ms.
>
> Anyway -- this data mostly validates my opinion that most of the
> optimization efforts really need to be focused on Zend\Di before
> anything else and it is my understanding that compiled DI definitions
> will help quite a bit with this.
>
> Hope this clarifies any lingering questions about ZF2 performance.
>
> --
> Evan Coury



--
Sascha-Oliver Prolic

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

Pádraic Brady
In reply to this post by EvanDotPro
If there's any interest, it should be trivial to add some
configuration of ZF2 as a benchmark target to Paul M. Jones'
benchmarking testbed. I used it about a year ago to gain some reliable
data on framework/language performance for an internal study (I have a
modified fork sitting around on Github:
https://github.com/padraic/php-framework-benchmarks/tree/benchmark-2010-03).
Instead of relying on third hand, possibly dubious, benchmarks we'd
have something a bit more scientific and representative of where we
stand in relation to other frameworks and such. We really shouldn't
have to wait for third party's to tell us what the performance is like
when we can keep a running tab on it ourselves as the betas move us
closer to the mark.

Paddy

2012/2/24 Evan Coury <[hidden email]>:

> 2012/2/23 Tomáš Fejfar <[hidden email]>
>>
>> I seems I'm not the only one to see the speed as a problem.
>>
>> http://www.enrise.com/2012/02/zend-framework-2-performance/
>
>
> Enrise is a great company and the author of that article did his homework
> before publishing those results. To quote the end of that article:
>
>> So, can we conclude that ZF2’s performance sucks? No, definitely not.
>>
>> Don’t forget it’s still in beta and I’m using a standard skeleton without
>> any optimizations like caching and class map autoloading. And in this
>> respect ZF2 has much more to offer than ZF1.
>>
>>
>> Before publishing I’ve discussed the results of this benchmark on
>> freenode.net/#zftalk.2 to find out what the problem could be. Matthew Weier
>> O’Phinney pointed out that the bulk of program execution right now is in the
>> DI container. They know how to address this, but have lowered its priority
>> in favor of finishing features needed.
>>
>>
>> Matthew said; “I’d also argue it’s premature to report benchmarks at this
>> point. We’re well aware of issues currently, but plan to address them
>> pre-stable release” And he’s completely right. This benchmark was meant
>> purely to see if the article from piprime.fr made any sense. And it’s a
>> starting point for me to see what you can do with the different
>> optimizations and what their performance impact is.
>>
>>
>> There will be a follow-up to this article, hopefully with the conclusion
>> that, with all possible optimizations correctly configured, ZF2 will kick
>> ZF1′s ass!
>
>
> It can be concluded that this benchmark simply mirrors what we've already
> mentioned: autoloading and runtime DI definitions make up a bulk of the
> request time.
>
> --
> Evan Coury



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

gargoyle-3
In reply to this post by Dennis Lassiter
Every day is a learning day! I don't think I have ever used array_key_exists().

How does that compare to:-

$keys = array_keys($array);
isset($keys['foo']) ?


Or for php 5.4 goodness::

isset(array_keys($array)['foo']);


Paul



On 24 Feb 2012, at 13:52, Dennis Lassiter wrote:

> Hi Sascha,
>
> array_key_exists and isset work differently. Isset also returns false if the value is null:
>
> <?php
>
> $array = array('foo' => 'bar', 'lorem' => 'ipsum', 'somethingelse' => null);
>
> array_key_exists('foo', $array); // true
> array_key_exists('lorem', $array); // true
> array_key_exists('somethingelse', $array); // true
>
> isset($array['foo']); // true
> isset($array['lorem']); // true
> isset($array['somethingelse']); // false
>
> ?>
>
> Cheers,
>
> Dennis Lassiter
>
> -----Ursprüngliche Nachricht-----
> Von: Sascha-Oliver Prolic [mailto:[hidden email]]
> Gesendet: Freitag, 24. Februar 2012 14:37
> An: Evan Coury
> Cc: <[hidden email]>
> Betreff: Re: [zf-contributors] ZF2 speed
>
> Hi Evan,
>
> thanks for the docs. One thing i saw is the massive usage of array_key_exists, so i want to ask, whether we could  remove them in favor of isset.
> I published a small benchmark at https://gist.github.com/1900978.
> isset is 4-5 times faster than array_key_exists and i don't see the extra benefit in the usage of that function.
>
> Regards
>
> Sascha-Oliver Prolic
>
> 2012/2/24 Evan Coury <[hidden email]>:
>> For the interested, here's the top 99 (100 excluding main()) methods
>> sorted by exclusive execution time:
>>
>> https://docs.google.com/spreadsheet/ccc?key=0AqfVpJyG6BjsdFBGSk1jdDQ3Z
>> EFDcTVFVTg4Mjk1WGc
>>
>> The list is generated using xhprof with the latest skeleton +
>> EdpSuperluminal + APC to eliminate noise from autoloading time.
>> Looking at the first sheet, you'll notice it's mostly DI runtime
>> definition related stuff.
>>
>> On the second sheet of that spreadsheet is the same benchmark ran
>> without using Zend\Di. I replaced it with my own drop-in replacement
>> class: https://gist.github.com/1896972. Once you take away autoloading
>> and Zend\Di, there are very few things that stand out as performance
>> culprits (though that call to date() that takes 8% of the runtime,
>> 3.5ms, does seem a bit strange).
>>
>> TL;DR: With Zend\Di, the total execution time was around 210ms.
>> Bypassing Zend\Di, the total execution time was around 42ms.
>>
>> Anyway -- this data mostly validates my opinion that most of the
>> optimization efforts really need to be focused on Zend\Di before
>> anything else and it is my understanding that compiled DI definitions
>> will help quite a bit with this.
>>
>> Hope this clarifies any lingering questions about ZF2 performance.
>>
>> --
>> Evan Coury
>
>
>
> --
> Sascha-Oliver Prolic
>

Reply | Threaded
Open this post in threaded view
|

Re: ZF2 speed

EvanDotPro
In reply to this post by Sascha-Oliver Prolic
On Fri, Feb 24, 2012 at 6:37 AM, Sascha-Oliver Prolic
<[hidden email]> wrote:
>
> Hi Evan,
>
> thanks for the docs. One thing i saw is the massive usage of
> array_key_exists, so i want to ask, whether we could  remove them in
> favor of isset.
> I published a small benchmark at https://gist.github.com/1900978.
> isset is 4-5 times faster than array_key_exists and i don't see the
> extra benefit in the usage of that function.

Aside from what was already mentioned (array_key_exists behaves
differently than isset), also please keep in mind that even with 796
calls to array_key_exists (yeah, that's pretty high), it still only
accounts for 0.9% (2.124ms) of the execution time when using DI right
now. So even if we reduced that to **zero**, the largest gain we'd see
is 2ms, or under 1%. Also, most of that seems to come from DI (see my
non-DI benchmark, there's only 57 calls to array_key_exists totaling
0.146ms). We should probably give Ralph a chance with compiled DI
definitions and any other DI optimizations he might have in mind
before we get out our pitch forks.

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

AW: [zf-contributors] ZF2 speed

Dennis Lassiter
In reply to this post by gargoyle-3
Paul,

I tried this just for fun, and it turns out that it's actually slower. Who would have guessed, besides probably everybody :-)

- Dennis

-----Ursprüngliche Nachricht-----
Von: Paul Court [mailto:[hidden email]] Im Auftrag von Paul Court
Gesendet: Freitag, 24. Februar 2012 15:16
An: [hidden email]
Betreff: Re: [zf-contributors] ZF2 speed

Every day is a learning day! I don't think I have ever used array_key_exists().

How does that compare to:-

$keys = array_keys($array);
isset($keys['foo']) ?


Or for php 5.4 goodness::

isset(array_keys($array)['foo']);


Paul



On 24 Feb 2012, at 13:52, Dennis Lassiter wrote:

> Hi Sascha,
>
> array_key_exists and isset work differently. Isset also returns false if the value is null:
>
> <?php
>
> $array = array('foo' => 'bar', 'lorem' => 'ipsum', 'somethingelse' =>
> null);
>
> array_key_exists('foo', $array); // true array_key_exists('lorem',
> $array); // true array_key_exists('somethingelse', $array); // true
>
> isset($array['foo']); // true
> isset($array['lorem']); // true
> isset($array['somethingelse']); // false
>
> ?>
>
> Cheers,
>
> Dennis Lassiter
>
> -----Ursprüngliche Nachricht-----
> Von: Sascha-Oliver Prolic [mailto:[hidden email]]
> Gesendet: Freitag, 24. Februar 2012 14:37
> An: Evan Coury
> Cc: <[hidden email]>
> Betreff: Re: [zf-contributors] ZF2 speed
>
> Hi Evan,
>
> thanks for the docs. One thing i saw is the massive usage of array_key_exists, so i want to ask, whether we could  remove them in favor of isset.
> I published a small benchmark at https://gist.github.com/1900978.
> isset is 4-5 times faster than array_key_exists and i don't see the extra benefit in the usage of that function.
>
> Regards
>
> Sascha-Oliver Prolic
>
> 2012/2/24 Evan Coury <[hidden email]>:
>> For the interested, here's the top 99 (100 excluding main()) methods
>> sorted by exclusive execution time:
>>
>> https://docs.google.com/spreadsheet/ccc?key=0AqfVpJyG6BjsdFBGSk1jdDQ3
>> Z
>> EFDcTVFVTg4Mjk1WGc
>>
>> The list is generated using xhprof with the latest skeleton +
>> EdpSuperluminal + APC to eliminate noise from autoloading time.
>> Looking at the first sheet, you'll notice it's mostly DI runtime
>> definition related stuff.
>>
>> On the second sheet of that spreadsheet is the same benchmark ran
>> without using Zend\Di. I replaced it with my own drop-in replacement
>> class: https://gist.github.com/1896972. Once you take away
>> autoloading and Zend\Di, there are very few things that stand out as
>> performance culprits (though that call to date() that takes 8% of the
>> runtime, 3.5ms, does seem a bit strange).
>>
>> TL;DR: With Zend\Di, the total execution time was around 210ms.
>> Bypassing Zend\Di, the total execution time was around 42ms.
>>
>> Anyway -- this data mostly validates my opinion that most of the
>> optimization efforts really need to be focused on Zend\Di before
>> anything else and it is my understanding that compiled DI definitions
>> will help quite a bit with this.
>>
>> Hope this clarifies any lingering questions about ZF2 performance.
>>
>> --
>> Evan Coury
>
>
>
> --
> Sascha-Oliver Prolic
>


12