You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
😐**Logarithmic:** The runtime grows proportionally to the [logarithm](https://www.bbc.co.uk/bitesize/guides/zn3ty9q/revision/1) of the input size.</summary>
67
+
☺️**Logarithmic:** The runtime grows proportionally to the [logarithm](https://www.bbc.co.uk/bitesize/guides/zn3ty9q/revision/1) of the input size.</summary>
66
68
69
+
An example is finding a string in a sorted list. Each time we can look in the middle of the list, and halve the number of entries we need to consider next time by looking either in the half before or the half after that element.
😨 **Linear:** The runtime grows proportionally to the input size.</summary>
84
+
🙂 **Linear:** The runtime grows proportionally to the input size.</summary>
85
+
86
+
An example is finding an element by value in an un-sorted list. To be sure we find the element, we may need to look through every element in the list and check if it's the one we're looking for.
87
+
88
+
If we double the length of the list, we need to check twice as many elements.
What does this mean? It means that the time is the square of the input size: n\*n.
110
117
118
+
An example is finding which elements in an array are present more than once. For each element, we need to check every other element in the same array to see if they're equal. If we double the number of elements in the array, we _quadruple_ the number of checks we need to do.
119
+
111
120
<summary>
112
121
113
-
😰**Quadratic:** The runtime grows proportionally to the square of the input size.</summary>
122
+
😨**Quadratic:** The runtime grows proportionally to the square of the input size.</summary>
114
123
115
124
</details>
116
125
@@ -144,6 +153,8 @@ Oh where have we seen this sequence of numbers before? ;)
144
153
145
154
😱 **Exponential:** The runtime grows exponentially with the input size.</summary>
146
155
156
+
An example is making a list of every _combination_ of ever element in a list (so if we have `[1, 2, 3]` and want to make all the combinations: `[]`, `[1]`, `[2]`, `[3]`, `[1, 2]`, `[1, 3]`, `[2, 3]`, `[1, 2, 3]`).
157
+
147
158
</details>
148
159
149
160
You will explore this theory in your backlog, but you will find that you already have a basic understanding of this idea. No really! Let's look at these algorithms in real life:
@@ -163,8 +174,12 @@ You will explore this theory in your backlog, but you will find that you already
163
174
[LABEL=Quadratic Time]
164
175
- Everyone at a party shaking hands with everyone else. If you double the number of people (n), the number of handshakes increases much faster (roughly n \* n). This is like nesting a loop inside a loop.
165
176
[LABEL=Exponential Time]
166
-
- Trying every possible combination to unlock a password. Each extra character dramatically increases the possibilities. This is like naive recursion; we'll talk about this more later.
177
+
- Trying every possible combination to unlock a password. Each extra character dramatically increases the possibilities.
167
178
{{< /label-items >}}
168
179
169
180
> [!TIP]
170
181
> Big-O notation also describes space complexity (how memory use grows). Sometimes an algorithm's time complexity is different from its space complexity. We have focused on time here, but you'll meet space complexity analysis in the assigned reading.
182
+
183
+
Big-O notation is focused on the _trend_ of growth, not the exact growth.
184
+
185
+
Think about strings: one character may take up one byte or four. If we double the length of the string, we don't check which characters are in the string. We just think about the **trend**. The string will take _about_ twice as much space. If the string only has four-byte characters, and we add one-byte characters, the string is _still_ growing linearly, even though it may not take _exactly_ double the space.
Copy file name to clipboardExpand all lines: common-content/en/module/complexity/memory-consumption/index.md
+9-6Lines changed: 9 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,12 @@
1
1
+++
2
2
title = "Memory consumption"
3
3
description="Memory is finite"
4
+
time = 30
5
+
emoji = "🥪"
4
6
[build]
5
7
render = 'never'
6
8
list = 'local'
7
9
publishResources = false
8
-
time = 30
9
-
emoji= "🥪"
10
10
[objectives]
11
11
1="Quantify the memory used by different arrays"
12
12
+++
@@ -19,7 +19,7 @@ Think back to Chapter 7 of <cite>How Your Computer Really Works</cite>.
19
19
20
20
```mermaid
21
21
graph LR
22
-
CPU -->|️ Fastest: Smallest| Cache -->|Fast: Small| RAM -->|Slow : Big| Disk -->|Slowest: Vast| Network
22
+
CPU -->|️ Fastest and Smallest| Cache -->|Fast and Small| RAM -->|Slow and Big| Disk -->|Slowest and Vast| Network
23
23
```
24
24
25
25
At each stage there are **limits** to **how fast** you can get the data and **how much** data you can store. Given this constraint, we need to consider how much memory our programs consume.
@@ -34,11 +34,14 @@ const userRoles = ["Admin", "Editor", "Viewer"]; //An array of 3 short strings
34
34
constuserProfiles= [ {id:1, name:"Farzaneh", role:"Admin", preferences: {...}}, {id:2, name:"Cuneyt", role:"Editor", preferences: {...}} ]; // An array of 2 complex objects
35
35
```
36
36
37
-
Different kinds of data have different memory footprints:
37
+
Different kinds of data have different memory footprints. All data is fundamentally stored as bytes. We can form intuition for how much memory a piece of data takes:
38
38
39
-
- Numbers or booleans use less memory than objects
39
+
- Numbers are typically stored as 8 bytes. In some languages, you can define numbers which take up less space (but can store a smaller range of values).
40
+
- Each character in an ASCII string takes 1 byte. More complex characters may take more bytes. The biggest characters take up to 4 bytes.
40
41
- The longer a string, the more bytes it consumes.
41
-
- Objects and arrays need memory for their internal organisation _as well_ as the data itself.
42
+
- Objects and arrays are stored in different ways in different languages. But they need to store _at least_ the information contained within them.
43
+
- This means an array of 5 elements will use _at least_ as much memory as the 5 elements would on their own.
44
+
- And objects will use _at least_ as much memory as all of the _values_ inside the object (and in some languages, all of the keys as well).
42
45
43
46
More complicated elements or more properties need more memory. It matters what things are made of. All of this data added up is how much _space_ our program takes.
Copy file name to clipboardExpand all lines: common-content/en/module/complexity/n+1/index.md
+14-10Lines changed: 14 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,11 @@
1
1
+++
2
2
title = "N+1 Query Problem"
3
+
time = 60
4
+
emoji = "🎟️"
3
5
[build]
4
6
render = 'never'
5
7
list = 'local'
6
8
publishResources = false
7
-
time = 60
8
-
emoji= "🎟️"
9
9
[objectives]
10
10
1="Define the n+1 query problem"
11
11
2="List effective strategies to reduce database queries"
@@ -45,7 +45,14 @@ We've already seen that every query adds network delay and processing time. This
45
45
46
46
The server has to handle each request individually, consuming resources (CPU, memory, connections). If many users trigger this N+1 pattern at once, the database can slow down for everyone, or even fall over entirely.
47
47
48
-
This N+1 problem can happen with any database interaction if you loop and query individually. Understanding this helps you write backend code that doesn't accidentally overload the database.
48
+
This N+1 problem can happen with any database interaction if you loop and query individually. Understanding this helps you write code that doesn't accidentally overload the database.
49
+
50
+
{{<
51
+
multiple-choice
52
+
question="What is the N+1 Query Problem?"
53
+
answers="Fetching N items plus 1 extra backup item. | Making 1 query to get a list, then N separate queries to get details for each item in the list. | A query that is N times too complex. | Trying N+1 different network endpoints."
54
+
feedback="No, but flip this and try again? | Right! That's a clear description. | No, this is so vague it describes nothing. | No, it's not about network endpoints."
55
+
correct="1">}}
49
56
50
57
### 📦 What to do instead
51
58
@@ -55,11 +62,8 @@ The real `/home `endpoint avoids these problems by using efficient strategies:
55
62
**Caching**: Store results so you don't have to ask the network again. Ask for only new changes in future.
56
63
**Pagination**: Ask for only the first page of results. Load more later if the user scrolls or clicks "next".
57
64
58
-
All these are ways to save the data we need, close to where we need it. But each strategy also has downsides.
65
+
All these are ways to save the data we need, close to where we need it. But each strategy also has downsides.
59
66
60
-
{{<
61
-
multiple-choice
62
-
question="What is the N+1 Query Problem?"
63
-
answers="Fetching N items plus 1 extra backup item. | Making 1 query to get a list, then N separate queries to get details for each item in the list. | A query that is N times too complex. | Trying N+1 different network endpoints."
64
-
feedback="No, but flip this and try again? | Right! That's a clear description. | No, this is so vague it describes nothing. | No, it's not about network endpoints."
65
-
correct="1">}}
67
+
* Batching may reduce our responsiveness. It will probably take longer to fetch three users' blooms than one user's blooms. If we'd just asked for one user's blooms, then the next user's, we probably probably could've showed the user _some_ results sooner. Batching forces us to wait for _all_ of the results before we show anything.
68
+
* Caching may result in stale results. If we store a user's most recent blooms, and when they re-visit the page we don't ask the database for the most recent blooms, it's possible we'll return old results missing the newest blooms.
69
+
* Pagination means the user doesn't have complete results up-front. If they want to ask a question like "has this user ever bloomed the word cheese", they may need to keep scrolling and searching to find the answer (with each scroll requiring a separate network call and database lookup).
Copy file name to clipboardExpand all lines: common-content/en/module/complexity/operations/index.md
+7-5Lines changed: 7 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,11 @@
1
1
+++
2
2
title = '"Expensive" Operations'
3
+
time = 30
4
+
emoji= "🧮"
3
5
[build]
4
6
render = 'never'
5
7
list = 'local'
6
8
publishResources = false
7
-
time = 30
8
-
emoji= "🧮"
9
9
[objectives]
10
10
1="Explain what the significant/expensive operations for a particular algorithm are likely to be"
11
11
2="Quantify the number of significant operations taken by a particular algorithm"
@@ -15,7 +15,7 @@ Let's think about Purple Forest from the [Legacy Code](https://github.com/CodeYo
15
15
16
16
When we build the timeline of blooms on the homepage, we call an endpoint `/home`. This returns an array of objects, blooms, produced by people we follow, plus our own blooms, sorted by timestamp. We stuff this in our state object (and cache _that_ in our local storage).
17
17
18
-
There are many different ways we could get and show this information. Some ways are {{<tooltiptitle="better">}}
18
+
There are many different ways we could get and show this information in our frontend. Some ways are {{<tooltiptitle="better">}}
19
19
Here we are defining better as faster. We might at other times define better as _simpler_, _clearer_, or _safer_.
20
20
{{</tooltip>}} than others.
21
21
@@ -36,7 +36,7 @@ What if we had tried any of the following strategies:
36
36
1. Request our own blooms
37
37
1. Merge all the arrays
38
38
1. Sort by timestamp
39
-
1. Display blooms!
39
+
1. Display blooms
40
40
41
41
#### 3. Get ALL Blooms & People, then Loop & Filter
42
42
@@ -47,7 +47,7 @@ What if we had tried any of the following strategies:
47
47
1. Sort by timestamp
48
48
1. Display blooms
49
49
50
-
Given what we've just thought about, how efficient are these programs? How could you make them more efficient? Write your ideas down in your notebook.
50
+
Given what we've just thought about, how efficient are these programs? Which is going to be fastest or slowest? Which is going to use the most or least memory? How could you make them more efficient? Write your ideas down in your notebook.
51
51
52
52
Our end state is always to show the latest blooms that meet our criteria. How we produce that list determines how quickly our user gets their page. This is very very important. After just **three seconds**, half of all your users have given up and left.
53
53
@@ -58,3 +58,5 @@ The Purple Forest application does not do most of this work on the front end, bu
58
58
1. Number of network calls
59
59
60
60
This is because some operations are more {{<tooltiptitle="expensive">}}Expensive operations consume a lot of computational resources like CPU time, memory, or disk I/O.{{</tooltip>}} than others.
61
+
62
+
The _order_ also matters. In all of the above strategies, we filter the blooms _before_ sorting them. Sorting isn't a constant-time operation, so it takes more time to sort more data. If in the first strategy we had sorted _all_ of the blooms before we filtered down to the just the ones we cared about, we would have spent a lot more time sorting blooms we don't care about.
0 commit comments