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