Mastering PyCharm Transcripts
Chapter: Performance and profiling
Lecture: Optimizing the JSON search API

Login or purchase this course to watch this video and the rest of the course contents.
0:02 So we got our information about the performance here
0:05 none of these are acceptable speeds
0:09 300 milliseconds or above this is probably the worst,
0:12 but let's go ahead and start with this one in terms of trying to optimize this.
0:16 So here we are going to,
0:20 and we're doing this query and we'll get it back
0:22 and there's really very little to do over here
0:26 you'll see under search, this is zero milliseconds,
0:34 the time actually is way, way, way down here
0:40 but it's in this whole create connection send output
0:43 it's down on the network layer,
0:46 there's nothing that we're doing here that we're going to actually make faster.
0:52 So let's think about how we can optimize this.
0:55 One of the things we could do,
0:57 let's suppose we're going to call this over and over
1:00 let's suppose we're going to go over here,
1:02 I want to call this ten times or something,
1:06 because optimizing it once, there's not a whole lot we can do here
1:09 but if we say this code is actually called a bunch of times
1:15 like it's in a web app, the web app starts up and gets going,
1:18 something like that might make sense to think about what we're about to do,
1:21 so I run it without any optimizations
1:25 you can see it's doing its thing, okay, great.
1:29 So we go back over here to our services
1:32 one of the things that's really easy is we could say
1:35 let's just cash the output,
1:38 how often does the content on change;
1:41 a couple times a week you, if we open our app, do some work and close it
1:46 it is probably safe to just take the results.
1:49 So one of the things we can do is we can use this thing called functools,
1:53 so we can say import functools
1:56 and in here there's a caching decorator, momento type thing
2:00 and what it will do is, if it sees an argument it will record the results
2:05 and if it sees that argument again, it's just going to say
2:08 hey I already know the answer to this question, it is whatever, right,
2:12 whatever it saw from the last time.
2:13 So we can come here and say lru_cashe,
2:17 so we'll come down here and we'll set the lru cashe
2:22 and this is going to basically remember any search strings
2:25 and if it sees the same search, it's going to say the same answer,
2:28 and so we could search for many things
2:30 and it would give us the different corresponding answers,
2:32 but if it ever sees a repeated search, it's going to just give back the same answer.
2:37 So let's go ahead and run this again, notice that one was slower,
2:42 but now notice, there's basically no lag when we hit to the search section,
2:46 the other stuff is still slow, but search it's blazing.
2:49 So that's really cool, we're going to try
2:52 to make use of this idea of caching as an optimization
2:54 partly because we're not really doing interesting stuff
2:57 so we kind of got to make up some examples,
2:59 but this is really quite cool.
3:01 One caveat is the stuff that goes in the perimeter list here must be hashable,
3:06 strings are hashable, so this works.
3:08 Okay, so that actually made this really fast,
3:11 let's run this again and just see,
3:17 of course we did it, ten times as much, but that's ok
3:20 we can still look at the call graph and just zoom in and see what's going on over here,
3:25 so down here we have our search,
3:28 it was only called one time and it did take 280 milliseconds,
3:31 we can't really make it faster
3:33 unless we actually were to go and start saving that to disk
3:36 but even though these were called 9 times that one was called once
3:39 because we asked for the same search information over and over,
3:43 so once it got warmed up, it goes really, really fast
3:47 so I think that's about as good as it's going to get
3:49 unless I get my network faster right now.