WEBVTT NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com 00:00:01.046 --> 00:00:04.856 align:middle We've just updated our code to make a COUNT query instead of querying 00:00:04.916 --> 00:00:07.226 align:middle for all the comments for a user... 00:00:07.466 --> 00:00:08.626 align:middle just to count them. 00:00:09.236 --> 00:00:12.136 align:middle So, the page will definitely be faster. 00:00:12.536 --> 00:00:15.356 align:middle Right? Are you absolutely sure? 00:00:15.906 --> 00:00:17.676 align:middle Well, I think it will be faster... 00:00:17.886 --> 00:00:20.816 align:middle but sometimes making one part of your code faster... 00:00:20.946 --> 00:00:23.016 align:middle will make other parts slower. 00:00:23.866 --> 00:00:27.596 align:middle Fortunately, Blackfire has a special way to prove 00:00:27.746 --> 00:00:30.426 align:middle that a performance tweak does in fact help. 00:00:31.116 --> 00:00:34.076 align:middle Let's profile the page now - I'll refresh... 00:00:37.306 --> 00:00:38.606 align:middle then click to profile. 00:00:40.076 --> 00:00:44.506 align:middle Give it a name to stay organized [Recording] Show page after count query. 00:00:48.006 --> 00:00:50.006 align:middle Ok! Let's go see the call graph! 00:00:52.206 --> 00:00:57.686 align:middle https://bit.ly/sfcast-bf-profile2 Hey! 00:00:57.686 --> 00:01:05.266 align:middle 270 milliseconds total time - the last one was 415. 00:01:05.266 --> 00:01:05.986 align:middle So it is faster. 00:01:05.986 --> 00:01:07.186 align:middle We win! Tutorial over! 00:01:07.186 --> 00:01:08.606 align:middle Well... yeah, I agree: it does look faster. 00:01:08.606 --> 00:01:13.596 align:middle But an important aspect of optimization is understanding why something is faster. 00:01:13.986 --> 00:01:16.426 align:middle Like, did this reduce CPU time? 00:01:16.536 --> 00:01:17.886 align:middle I/O wait time? 00:01:18.196 --> 00:01:23.376 align:middle And, maybe more importantly, did this change cause anything to be worse? 00:01:24.206 --> 00:01:29.586 align:middle For example, a change might decrease CPU time, but increase memory. 00:01:30.236 --> 00:01:33.406 align:middle If that happened, would the change really be a good one? 00:01:33.896 --> 00:01:34.636 align:middle It depends. 00:01:35.306 --> 00:01:42.426 align:middle This leads me to one of my favorite tools from Blackfire: the ability to compare profiles. 00:01:43.576 --> 00:01:48.386 align:middle Click back to your dashboard: the top two profiles are from the initial profile 00:01:48.526 --> 00:01:51.096 align:middle and then the page after using the COUNT query. 00:01:51.846 --> 00:01:56.806 align:middle On the right, hover over the "Compare" button on the original, click, then click the new one. 00:01:58.856 --> 00:02:05.516 align:middle Say hello to the comparison view: https://bit.ly/sf-bf-compare1-2. 00:02:05.886 --> 00:02:07.956 align:middle Everything that's faster, or "better" is in blue. 00:02:07.956 --> 00:02:10.226 align:middle Anything that's slower or worse will be in red. 00:02:10.296 --> 00:02:15.026 align:middle And yea, it looks like the new profile is better in every single category. 00:02:15.746 --> 00:02:21.776 align:middle Ok, the I/O wait is higher - but .1 millisecond higher - that's just "noise". 00:02:22.496 --> 00:02:26.856 align:middle Anyways, the comparison proves that this was a good change. 00:02:27.546 --> 00:02:29.716 align:middle Really, it's a huge win! 00:02:30.646 --> 00:02:32.696 align:middle On the call graph, in the darkest blue, 00:02:33.016 --> 00:02:36.966 align:middle the critical path this time is the path that improved the most. 00:02:37.746 --> 00:02:39.626 align:middle Click the UnitOfWork call now. 00:02:40.226 --> 00:02:44.186 align:middle Wow. The inclusive time is down by 90 milliseconds 00:02:44.486 --> 00:02:48.436 align:middle and even the memory plummeted: down 1.39 megabytes. 00:02:48.436 --> 00:02:53.076 align:middle But wait. One of the items on top is called "SQL Queries". 00:02:54.016 --> 00:02:57.216 align:middle The total query time is less than before... 00:02:57.336 --> 00:03:00.316 align:middle but we've added 5 more queries. 00:03:00.976 --> 00:03:03.066 align:middle We removed these 18 queries... 00:03:03.206 --> 00:03:05.536 align:middle but added 23 new ones. 00:03:06.046 --> 00:03:07.346 align:middle Is that a problem? 00:03:07.846 --> 00:03:08.726 align:middle Probably not. 00:03:09.566 --> 00:03:11.926 align:middle Overall, this change was good. 00:03:12.316 --> 00:03:18.636 align:middle And if having too many queries does create a real problem - not just an imaginary one 00:03:18.636 --> 00:03:22.406 align:middle of "too many queries" - Blackfire will help us discover that. 00:03:23.246 --> 00:03:28.136 align:middle The big takeaway here is: don't just assume that a performance enhancement... 00:03:28.186 --> 00:03:29.616 align:middle is actually better. 00:03:30.316 --> 00:03:36.016 align:middle We'll see this later - not every change we'll do in this tutorial will prove to be a good one. 00:03:36.906 --> 00:03:43.796 align:middle Next: Blackfire has a deep understanding of PHP, database queries, Redis calls and even libraries 00:03:43.946 --> 00:03:49.016 align:middle like Symfony, Doctrine, Magento, Composer, eZ platform, Wordpress and others. 00:03:49.946 --> 00:03:54.746 align:middle Thanks to that, it automatically detects problems and recommends solutions.