WEBVTT 1 00:00:00.310 --> 00:00:02.570 Hi guys, just a quick video to show you 2 00:00:02.570 --> 00:00:05.550 how to cache functions. 3 00:00:05.550 --> 00:00:07.880 Here's a little problem with our convert function. 4 00:00:07.880 --> 00:00:10.130 Imagine that this convert function is getting called 5 00:00:10.130 --> 00:00:13.770 all over our application, but many different parts of it, 6 00:00:13.770 --> 00:00:16.260 and it's converting a lot of different currencies 7 00:00:16.260 --> 00:00:17.093 all the time. 8 00:00:17.093 --> 00:00:19.400 Imagine we have some sort of application 9 00:00:19.400 --> 00:00:23.040 that does currency conversion for our users. 10 00:00:23.040 --> 00:00:25.190 You'll know by reading the documentation 11 00:00:25.190 --> 00:00:29.250 that this self.latest only changes once an hour. 12 00:00:29.250 --> 00:00:33.260 So if you make this request a thousand times an hour, 13 00:00:33.260 --> 00:00:35.933 you're actually always gonna get the same value back, 14 00:00:36.820 --> 00:00:38.980 which means that making the request 15 00:00:38.980 --> 00:00:40.840 and actually interacting with the server, 16 00:00:40.840 --> 00:00:41.860 sending them data, 17 00:00:41.860 --> 00:00:44.330 getting them to send you data back and all that, 18 00:00:44.330 --> 00:00:46.600 is a bit of a waste, 19 00:00:46.600 --> 00:00:49.000 just because it's never gonna change. 20 00:00:49.000 --> 00:00:52.330 Now if you are on a paid plan, it does change more often, 21 00:00:52.330 --> 00:00:53.470 but because we're not 22 00:00:53.470 --> 00:00:56.350 and we don't really need the granularity 23 00:00:56.350 --> 00:00:57.940 of changing every minute, 24 00:00:57.940 --> 00:01:01.440 we can stay on the free plan and we can prevent our programme 25 00:01:01.440 --> 00:01:04.500 from making this request over and over again 26 00:01:04.500 --> 00:01:07.860 as we use the convert function. 27 00:01:07.860 --> 00:01:09.210 So what we're gonna do is, 28 00:01:09.210 --> 00:01:12.920 we're gonna first of all time the function. 29 00:01:12.920 --> 00:01:14.530 So we'll say import time. 30 00:01:14.530 --> 00:01:16.090 And then we're gonna say 31 00:01:16.090 --> 00:01:20.230 that the start time is time.time, 32 00:01:20.230 --> 00:01:23.200 and the end time is time.time, 33 00:01:23.200 --> 00:01:25.940 and then we're gonna print end minus start. 34 00:01:25.940 --> 00:01:29.080 What this is gonna give us here in our code is 35 00:01:29.080 --> 00:01:33.060 how long it takes for this convert function to run. 36 00:01:33.060 --> 00:01:35.770 So if we press app and play, 37 00:01:35.770 --> 00:01:39.550 you'll see that it takes about half a second to run. 38 00:01:39.550 --> 00:01:41.250 So that's quite slow. 39 00:01:41.250 --> 00:01:42.580 And it's normal, 40 00:01:42.580 --> 00:01:44.010 it's normal that it takes that amount of time 41 00:01:44.010 --> 00:01:46.210 because it has to send data over the internet, 42 00:01:46.210 --> 00:01:47.930 it has to wait for the server to process it, 43 00:01:47.930 --> 00:01:49.440 it has to wait for the server 44 00:01:49.440 --> 00:01:51.550 to send data back over the internet, 45 00:01:51.550 --> 00:01:53.240 and then it has to do some work. 46 00:01:53.240 --> 00:01:56.980 However, if we do this over and over, 47 00:01:56.980 --> 00:02:00.530 for example, let's do it three times, say, 48 00:02:00.530 --> 00:02:05.530 and we will actually do this three times. 49 00:02:05.600 --> 00:02:07.190 So I just copy and paste it three times, 50 00:02:07.190 --> 00:02:08.720 not the greatest thing to do, 51 00:02:08.720 --> 00:02:09.840 but just to show you 52 00:02:09.840 --> 00:02:11.630 that it always takes more or less the same amount of time. 53 00:02:11.630 --> 00:02:13.780 It always takes about half a second. 54 00:02:13.780 --> 00:02:16.640 So we're gonna go over to our open exchange file 55 00:02:16.640 --> 00:02:18.050 and we're gonna cache this function 56 00:02:18.050 --> 00:02:22.770 so that the subsequent times we use it, it's instant. 57 00:02:22.770 --> 00:02:26.250 There is a built-in module in Python called functools 58 00:02:26.250 --> 00:02:28.760 that we may have seen before. 59 00:02:28.760 --> 00:02:30.650 And the functools module 60 00:02:30.650 --> 00:02:33.410 has a functools.lru_cache. 61 00:02:36.342 --> 00:02:37.820 And we can define the maxsize, 62 00:02:37.820 --> 00:02:39.890 for example, to be two. 63 00:02:39.890 --> 00:02:44.890 So the lru_cache means least recently used. 64 00:02:45.440 --> 00:02:49.260 And the maxsize is how many elements will stay in the cache. 65 00:02:49.260 --> 00:02:52.810 So maybe we should first of all explain what a cache is. 66 00:02:52.810 --> 00:02:56.040 A cache is just a piece of storage 67 00:02:56.040 --> 00:02:58.260 that keeps data temporarily. 68 00:02:58.260 --> 00:03:02.050 And the data that it keeps is data that is used 69 00:03:02.050 --> 00:03:04.800 or needs to be used so that when you wanna use it again, 70 00:03:04.800 --> 00:03:07.740 or you wanna access that data again, it is very fast. 71 00:03:07.740 --> 00:03:09.290 So by caching this function, 72 00:03:09.290 --> 00:03:13.080 we're gonna put the arguments of the function 73 00:03:13.080 --> 00:03:16.830 and the result into this temporary storage. 74 00:03:16.830 --> 00:03:20.600 Whenever we use the function again with the same arguments, 75 00:03:20.600 --> 00:03:22.440 it's gonna get the data from the storage 76 00:03:22.440 --> 00:03:24.113 instead of running the function. 77 00:03:25.180 --> 00:03:27.760 So as long as the arguments don't change, 78 00:03:27.760 --> 00:03:29.520 the result will be instant. 79 00:03:29.520 --> 00:03:32.320 And that is why we've put a maxsize of two, 80 00:03:32.320 --> 00:03:34.730 because this has no arguments, 81 00:03:34.730 --> 00:03:39.383 so it's never gonna take up more than one slot in the cache. 82 00:03:40.650 --> 00:03:41.990 If you have arguments, 83 00:03:41.990 --> 00:03:44.200 then you may wanna increase your maxsize 84 00:03:44.200 --> 00:03:46.410 so that you can account for different permutations 85 00:03:46.410 --> 00:03:47.373 of the arguments. 86 00:03:48.350 --> 00:03:51.640 Let's run app.py again and you'll see how now, 87 00:03:51.640 --> 00:03:55.400 the first instance takes .65 seconds, 88 00:03:55.400 --> 00:03:58.680 but subsequent instance take five, essentially, 89 00:03:58.680 --> 00:04:01.910 nanoseconds, I think that is a very small amount of time. 90 00:04:01.910 --> 00:04:04.680 And you see that the programme did finish much quicker. 91 00:04:04.680 --> 00:04:06.570 There is a small problem with this though, 92 00:04:06.570 --> 00:04:08.930 which is that if we have this application running 93 00:04:08.930 --> 00:04:10.760 and it runs for a very long time, 94 00:04:10.760 --> 00:04:13.830 because this only ever appears in the cache once, 95 00:04:13.830 --> 00:04:15.010 there are no arguments, 96 00:04:15.010 --> 00:04:17.510 it will never get removed from the cache, 97 00:04:17.510 --> 00:04:20.050 which means that our application will always be limited 98 00:04:20.050 --> 00:04:25.050 to using the first request that it ever made to the server. 99 00:04:25.730 --> 00:04:28.260 If our application runs for longer than an hour, 100 00:04:28.260 --> 00:04:29.680 that means that after an hour, 101 00:04:29.680 --> 00:04:31.690 this response will be outdated 102 00:04:31.690 --> 00:04:33.730 because if we were to request it again, 103 00:04:33.730 --> 00:04:35.900 it would've changed in the server. 104 00:04:35.900 --> 00:04:38.000 What we wanna do is cache, 105 00:04:38.000 --> 00:04:40.180 but only up to an hour. 106 00:04:40.180 --> 00:04:42.730 And for that, we have to use a different package 107 00:04:42.730 --> 00:04:44.580 that we're going to look at in the next video. 108 00:04:44.580 --> 00:04:45.530 I'll see you there.