1
00:00:01,150 --> 00:00:02,580
‫Instructeur : Bon retour.

2
00:00:02,580 --> 00:00:05,000
‫Apprenons maintenant tout sur la boucle d'événement, qui

3
00:00:05,000 --> 00:00:08,150
‫est le cœur du Node. architecture js.

4
00:00:08,150 --> 00:00:10,580
‫Et c'est probablement la conférence la

5
00:00:10,580 --> 00:00:13,500
‫plus importante de cette section, alors assurez-vous de bien

6
00:00:13,500 --> 00:00:16,510
‫comprendre tout ce que je vous montre pendant cette vidéo.

7
00:00:16,510 --> 00:00:17,813
‫Alors, commençons.

8
00:00:18,800 --> 00:00:21,880
‫Donc, voici un schéma similaire à la dernière conférence

9
00:00:21,880 --> 00:00:25,170
‫afin que nous sachions exactement de quoi nous parlons ici.

10
00:00:25,170 --> 00:00:28,240
‫Donc, nous sommes toujours dans un processus Node dans le thread

11
00:00:28,240 --> 00:00:30,810
‫unique où s'exécute la boucle d'événement, d'accord ?

12
00:00:30,810 --> 00:00:32,530
‫Maintenant, la première chose que vous

13
00:00:32,530 --> 00:00:34,750
‫devez savoir est que la boucle d'événement est

14
00:00:34,750 --> 00:00:36,350
‫l'endroit où tout le code

15
00:00:36,350 --> 00:00:39,550
‫d'application qui se trouve à l'intérieur des fonctions de rappel est exécuté.

16
00:00:39,550 --> 00:00:43,640
‫Donc, fondamentalement, tout le code qui n'est pas du code de niveau supérieur

17
00:00:43,640 --> 00:00:45,250
‫s'exécutera dans la boucle d'événements.

18
00:00:45,250 --> 00:00:48,450
‫Certaines parties peuvent être déchargées vers le pool de threads comme

19
00:00:48,450 --> 00:00:50,140
‫nous l'avons vu dans la

20
00:00:50,140 --> 00:00:53,430
‫dernière conférence, mais c'est la boucle d'événements qui s'occupe de tout cela.

21
00:00:53,430 --> 00:00:56,370
‫Comme je l'ai déjà dit, c'est vraiment le

22
00:00:56,370 --> 00:00:58,360
‫cœur de l'architecture Node.

23
00:00:58,360 --> 00:01:01,660
‫Bon, maintenant, comme je l'ai mentionné plusieurs fois dans la première

24
00:01:01,660 --> 00:01:04,300
‫partie du cours, Node. js est entièrement construit

25
00:01:04,300 --> 00:01:05,860
‫autour de fonctions de rappel.

26
00:01:05,860 --> 00:01:08,160
‫Donc, des fonctions qui sont

27
00:01:08,160 --> 00:01:11,700
‫appelées dès qu'un travail est terminé dans le futur.

28
00:01:11,700 --> 00:01:12,960
‫Vous vous en souvenez ?

29
00:01:12,960 --> 00:01:15,310
‫Et cela fonctionne de cette façon parce

30
00:01:15,310 --> 00:01:17,750
‫que Node utilise une architecture déclenchée par

31
00:01:17,750 --> 00:01:20,480
‫des événements, ce dont nous allons parler dans

32
00:01:20,480 --> 00:01:22,100
‫l'une des prochaines vidéos.

33
00:01:22,100 --> 00:01:24,180
‫Mais ce que vous devez savoir

34
00:01:24,180 --> 00:01:26,020
‫pour l'instant, c'est que des

35
00:01:26,020 --> 00:01:31,020
‫choses comme notre application recevant une requête HTTP sur notre serveur ou un timer

36
00:01:31,130 --> 00:01:34,860
‫expirant ou un fichier se terminant à lire, tout cela émettra

37
00:01:34,860 --> 00:01:37,350
‫des événements dès qu'ils auront terminé leur

38
00:01:37,350 --> 00:01:40,150
‫travail, et notre événement loop va alors récupérer

39
00:01:40,150 --> 00:01:41,880
‫ces événements et appeler

40
00:01:41,880 --> 00:01:44,750
‫les fonctions de rappel associées à chaque événement.

41
00:01:44,750 --> 00:01:46,520
‫D'accord, ça a du sens ?

42
00:01:46,520 --> 00:01:49,680
‫Donc, encore une fois, la boucle d'événements reçoit des événements chaque

43
00:01:49,680 --> 00:01:51,800
‫fois que quelque chose d'important se produit,

44
00:01:51,800 --> 00:01:54,440
‫et appellera ensuite les rappels nécessaires tels que nous

45
00:01:54,440 --> 00:01:56,443
‫les définissons dans notre code.

46
00:01:57,300 --> 00:01:59,690
‫Donc, en résumé, on dit généralement

47
00:01:59,690 --> 00:02:02,600
‫que la boucle d'événements effectue l'orchestration, ce qui

48
00:02:02,600 --> 00:02:05,310
‫signifie simplement qu'elle reçoit des événements, appelle

49
00:02:05,310 --> 00:02:07,330
‫leurs fonctions de rappel et

50
00:02:07,330 --> 00:02:11,290
‫décharge les tâches les plus coûteuses vers le pool de threads.

51
00:02:11,290 --> 00:02:14,670
‫Maintenant, comment tout cela fonctionne-t-il réellement dans les coulisses ?

52
00:02:14,670 --> 00:02:17,960
‫Dans quel ordre ces rappels sont-ils exécutés ?

53
00:02:17,960 --> 00:02:20,543
‫Eh bien, c'est ce que nous allons découvrir ensuite.

54
00:02:21,460 --> 00:02:24,630
‫Alors, rappelez-vous, lorsque nous démarrons notre application Node,

55
00:02:24,630 --> 00:02:27,430
‫la boucle d'événements commence immédiatement à s'exécuter.

56
00:02:27,430 --> 00:02:29,720
‫Maintenant, la boucle d'événements a plusieurs phases,

57
00:02:29,720 --> 00:02:32,330
‫et chaque phase a une file d'attente de

58
00:02:32,330 --> 00:02:35,060
‫rappels, qui sont les rappels provenant des événements

59
00:02:35,060 --> 00:02:36,690
‫que la boucle d'événements

60
00:02:36,690 --> 00:02:39,830
‫reçoit, comme nous en avons parlé dans la dernière diapositive.

61
00:02:39,830 --> 00:02:41,830
‫Maintenant, à certains endroits, vous lirez

62
00:02:41,830 --> 00:02:45,520
‫qu'il n'y a qu'une seule file d'attente de rappel ou une seule file d'attente

63
00:02:45,520 --> 00:02:49,290
‫d'événements, mais en fait, comme je l'ai dit, la boucle d'événements comporte de nombreuses

64
00:02:49,290 --> 00:02:52,290
‫phases où chaque phase a sa propre file d'attente de rappel.

65
00:02:52,290 --> 00:02:56,090
‫Voyons maintenant les quatre phases les plus importantes.

66
00:02:56,090 --> 00:02:58,090
‫Il y a une ou deux autres phases

67
00:02:58,090 --> 00:02:59,890
‫qui sont utilisées en interne par Node,

68
00:02:59,890 --> 00:03:01,360
‫mais celles-ci ne sont pas

69
00:03:01,360 --> 00:03:03,530
‫si importantes et je ne vais pas en parler.

70
00:03:03,530 --> 00:03:05,230
‫Ainsi, la première phase

71
00:03:05,230 --> 00:03:07,860
‫prend en charge les rappels des minuteurs

72
00:03:07,860 --> 00:03:10,880
‫expirés, par exemple, à partir de la fonction setTimeout().

73
00:03:10,880 --> 00:03:13,210
‫Ainsi, s'il y a des fonctions de rappel

74
00:03:13,210 --> 00:03:15,750
‫des temporisateurs qui viennent d'expirer, ce sont les premières

75
00:03:15,750 --> 00:03:18,010
‫à être traitées par la boucle d'événement.

76
00:03:18,010 --> 00:03:21,040
‫Si un temporisateur expire plus tard pendant le temps où

77
00:03:21,040 --> 00:03:23,370
‫l'une des autres phases est en

78
00:03:23,370 --> 00:03:26,860
‫cours de traitement, eh bien, le rappel de ce temporisateur ne sera

79
00:03:26,860 --> 00:03:30,450
‫appelé que dès que la boucle d'événement reviendra à cette première phase.

80
00:03:30,450 --> 00:03:31,580
‫Avoir du sens ?

81
00:03:31,580 --> 00:03:34,520
‫Et cela fonctionne comme ça dans les quatre phases.

82
00:03:34,520 --> 00:03:37,250
‫Ainsi, les rappels dans chaque file d'attente sont traités

83
00:03:37,250 --> 00:03:40,810
‫un par un jusqu'à ce qu'il n'y ait plus personne dans la

84
00:03:40,810 --> 00:03:44,630
‫file d'attente, et alors seulement, la boucle d'événements entrera dans la phase suivante.

85
00:03:44,630 --> 00:03:49,180
‫Ensuite, nous avons l'interrogation d'E/S et l'exécution de rappels d'E/S.

86
00:03:49,180 --> 00:03:52,840
‫Et encore une fois, n'oubliez pas que I/O signifie entrée/sortie.

87
00:03:52,840 --> 00:03:56,040
‫Ainsi, l'interrogation signifie essentiellement rechercher de nouveaux événements d'E/S

88
00:03:56,040 --> 00:03:58,060
‫prêts à être traités et

89
00:03:58,060 --> 00:04:00,890
‫les mettre dans la file d'attente de rappel.

90
00:04:00,890 --> 00:04:04,110
‫Et rappelez-vous que dans le contexte d'une application Node, les

91
00:04:04,110 --> 00:04:08,710
‫E/S signifient principalement des choses comme la mise en réseau et l'accès aux fichiers, et

92
00:04:08,710 --> 00:04:12,150
‫donc, c'est dans cette phase où probablement 99% de notre code

93
00:04:12,150 --> 00:04:14,270
‫est exécuté, simplement parce que

94
00:04:14,270 --> 00:04:16,640
‫dans une application Node typique, la majeure

95
00:04:16,640 --> 00:04:20,500
‫partie de ce que nous devons faire est lié à la mise

96
00:04:20,500 --> 00:04:23,170
‫en réseau et également à l'accès aux fichiers.

97
00:04:23,170 --> 00:04:26,490
‫La phase suivante concerne les rappels setImmediate, et setImmediate est

98
00:04:26,490 --> 00:04:29,250
‫un type spécial de minuteur que nous

99
00:04:29,250 --> 00:04:32,810
‫pouvons utiliser si nous voulons traiter les rappels immédiatement après la

100
00:04:32,810 --> 00:04:36,130
‫phase d'interrogation et d'exécution des E/S, ce qui peut

101
00:04:36,130 --> 00:04:39,173
‫être important dans certains cas d'utilisation plus avancés.

102
00:04:40,110 --> 00:04:40,943
‫D'accord.

103
00:04:40,943 --> 00:04:44,940
‫Et enfin, la quatrième phase concerne les rappels rapprochés, qui, encore une fois,

104
00:04:44,940 --> 00:04:47,530
‫ne sont pas si importants pour nous,

105
00:04:47,530 --> 00:04:50,820
‫mais je le mets quand même ici par souci d'exhaustivité.

106
00:04:50,820 --> 00:04:54,450
‫Fondamentalement, dans cette phase, tous les événements de fermeture sont

107
00:04:54,450 --> 00:04:58,920
‫traités, par exemple, lors de la fermeture d'un serveur Web ou d'un WebSocket.

108
00:04:58,920 --> 00:05:01,920
‫Ce sont donc les quatre phases de la boucle d'événement,

109
00:05:01,920 --> 00:05:05,400
‫mais en plus de ces quatre files d'attente de rappel que nous

110
00:05:05,400 --> 00:05:08,330
‫venons de voir, il existe en fait également

111
00:05:08,330 --> 00:05:11,600
‫deux autres files d'attente, la file d'attente nextTick() et l'autre file

112
00:05:11,600 --> 00:05:14,780
‫d'attente de microtâches, qui est principalement destinée aux promesses résolues.

113
00:05:14,780 --> 00:05:16,890
‫Si vous n'êtes pas familier avec

114
00:05:16,890 --> 00:05:20,240
‫les promesses, nous en parlerons un peu dans une section ultérieure.

115
00:05:20,240 --> 00:05:22,620
‫Quoi qu'il en soit, s'il y a des

116
00:05:22,620 --> 00:05:24,750
‫rappels dans l'une de ces deux files

117
00:05:24,750 --> 00:05:27,840
‫d'attente à traiter, ils seront exécutés juste après la fin de

118
00:05:27,840 --> 00:05:30,250
‫la phase actuelle de la boucle d'événements au lieu

119
00:05:30,250 --> 00:05:32,380
‫d'attendre que la boucle entière se termine.

120
00:05:32,380 --> 00:05:33,370
‫D'accord?

121
00:05:33,370 --> 00:05:36,680
‫Donc, en d'autres termes, après chacune de ces quatre

122
00:05:36,680 --> 00:05:40,340
‫phases, s'il y a des rappels dans ces deux files

123
00:05:40,340 --> 00:05:42,880
‫d'attente spéciales, ils seront exécutés immédiatement.

124
00:05:42,880 --> 00:05:46,030
‫Maintenant, par exemple, imaginez qu'une promesse résout et

125
00:05:46,030 --> 00:05:49,730
‫renvoie des données d'un appel d'API pendant que le rappel

126
00:05:49,730 --> 00:05:52,690
‫d'un temporisateur expiré est en cours d'exécution.

127
00:05:52,690 --> 00:05:56,050
‫Ainsi, dans ce cas, le rappel de promesse sera exécuté

128
00:05:56,050 --> 00:05:59,230
‫juste après la fin de celui du minuteur.

129
00:05:59,230 --> 00:06:00,490
‫D'accord?

130
00:06:00,490 --> 00:06:03,480
‫Et la même logique s'applique également à la file d'attente nextTick(),

131
00:06:03,480 --> 00:06:05,290
‫dont nous n'avons pas encore parlé.

132
00:06:05,290 --> 00:06:09,060
‫Donc, fondamentalement, traiter le nextTick () est une fonction que nous

133
00:06:09,060 --> 00:06:11,610
‫pouvons utiliser lorsque nous avons vraiment, vraiment besoin

134
00:06:11,610 --> 00:06:13,740
‫d'exécuter un certain rappel juste

135
00:06:13,740 --> 00:06:16,290
‫après la phase de boucle d'événement en cours.

136
00:06:16,290 --> 00:06:18,810
‫C'est un peu similaire à setImmediate, à

137
00:06:18,810 --> 00:06:21,540
‫la différence que setImmediate ne s'exécute qu'après la

138
00:06:21,540 --> 00:06:23,400
‫phase de rappel d'E/S.

139
00:06:23,400 --> 00:06:24,600
‫Ce qui est similaire,

140
00:06:24,600 --> 00:06:27,930
‫cependant, c'est que les deux sont destinés à des cas d'utilisation vraiment avancés,

141
00:06:27,930 --> 00:06:30,080
‫et nous n'aurons probablement même pas besoin d'eux

142
00:06:30,080 --> 00:06:31,580
‫tout au long de ce cours.

143
00:06:31,580 --> 00:06:34,660
‫Mais de toute façon, je voulais également inclure ces éléments plus

144
00:06:34,660 --> 00:06:36,700
‫complexes ici afin que vous ayez les outils

145
00:06:36,700 --> 00:06:38,940
‫dont vous avez besoin si vous avez vraiment

146
00:06:38,940 --> 00:06:42,980
‫besoin de creuser profondément dans Node. js si tu veux.

147
00:06:42,980 --> 00:06:46,210
‫Très bien, et avec cela, nous avons en fait terminé

148
00:06:46,210 --> 00:06:50,360
‫un tick de la boucle d'événements, et un tick n'est fondamentalement qu'un cycle

149
00:06:50,360 --> 00:06:51,580
‫dans cette boucle.

150
00:06:51,580 --> 00:06:54,840
‫Il est donc maintenant temps de décider si la boucle

151
00:06:54,840 --> 00:06:58,520
‫doit continuer jusqu'au prochain tick ou si le programme doit se terminer.

152
00:06:58,520 --> 00:07:00,720
‫Et comment Node fait-il cela ?

153
00:07:00,720 --> 00:07:02,310
‫Eh bien, c'est très simple.

154
00:07:02,310 --> 00:07:05,100
‫Node vérifie simplement s'il y a des

155
00:07:05,100 --> 00:07:08,440
‫temporisateurs ou des tâches d'E/S qui s'exécutent toujours en

156
00:07:08,440 --> 00:07:12,180
‫arrière-plan, et s'il n'y en a pas, il quittera l'application.

157
00:07:12,180 --> 00:07:15,430
‫Mais s'il y a des temporisateurs ou des tâches d'E/S en

158
00:07:15,430 --> 00:07:17,870
‫attente, eh bien, il continuera à exécuter

159
00:07:17,870 --> 00:07:20,500
‫la boucle d'événements et passera directement au tick suivant.

160
00:07:20,500 --> 00:07:22,030
‫Ainsi, par exemple, lorsque

161
00:07:22,030 --> 00:07:24,740
‫nous écoutons les requêtes HTTP entrantes comme nous

162
00:07:24,740 --> 00:07:27,770
‫l'avons fait dans notre projet de batterie de nœuds dans

163
00:07:27,770 --> 00:07:30,600
‫une section précédente, nous exécutions essentiellement une tâche d'E/S,

164
00:07:30,600 --> 00:07:32,320
‫et c'est pourquoi la boucle d'événement,

165
00:07:32,320 --> 00:07:34,640
‫et donc, Node. js, continuez

166
00:07:34,640 --> 00:07:38,600
‫à exécuter et continuez à écouter les nouvelles requêtes

167
00:07:38,600 --> 00:07:41,920
‫HTTP entrant au lieu de simplement quitter l'application.

168
00:07:41,920 --> 00:07:44,450
‫De plus, lorsque nous écrivons ou lisons un

169
00:07:44,450 --> 00:07:47,480
‫fichier en arrière-plan, il s'agit également d'une tâche d'E/S, et

170
00:07:47,480 --> 00:07:50,210
‫il est donc logique que l'application ne se ferme

171
00:07:50,210 --> 00:07:53,260
‫pas pendant qu'elle travaille avec ce fichier, n'est-ce pas ?

172
00:07:53,260 --> 00:07:55,780
‫D'accord, et c'est essentiellement ce que vous devez savoir

173
00:07:55,780 --> 00:07:57,930
‫sur le Node. boucle d'événement js.

174
00:07:57,930 --> 00:08:00,260
‫Si vous avez besoin de plus de détails que

175
00:08:00,260 --> 00:08:01,760
‫cela, eh bien, vous

176
00:08:01,760 --> 00:08:04,860
‫pouvez toujours essayer de lire la documentation officielle de Node, qui devrait

177
00:08:04,860 --> 00:08:07,060
‫être assez facile à comprendre à ce stade

178
00:08:07,060 --> 00:08:10,570
‫maintenant que vous comprenez déjà la plupart de la boucle d'événements de toute façon.

179
00:08:10,570 --> 00:08:12,830
‫Et je veux juste souligner qu'il

180
00:08:12,830 --> 00:08:15,940
‫est vraiment très important que vous compreniez correctement la boucle

181
00:08:15,940 --> 00:08:18,280
‫d'événements afin que vous puissiez écrire votre

182
00:08:18,280 --> 00:08:21,390
‫propre code performant et également déboguer votre propre code lorsque

183
00:08:21,390 --> 00:08:24,173
‫quelque chose ne va pas de manière inattendue.

184
00:08:25,720 --> 00:08:27,770
‫Et maintenant, juste pour finir, passons en revue certaines

185
00:08:27,770 --> 00:08:29,810
‫des choses dont nous avons parlé ici.

186
00:08:29,810 --> 00:08:32,490
‫Donc, en un mot, la chose la plus importante que je

187
00:08:32,490 --> 00:08:34,620
‫veux que vous compreniez de cette conférence, et

188
00:08:34,620 --> 00:08:36,740
‫peut-être de tout ce cours, est que la

189
00:08:36,740 --> 00:08:38,560
‫boucle d'événements est ce qui rend la

190
00:08:38,560 --> 00:08:41,630
‫programmation asynchrone possible dans Node. js, ce qui en fait

191
00:08:41,630 --> 00:08:45,190
‫la fonctionnalité la plus importante dans la conception de Node et la

192
00:08:45,190 --> 00:08:47,580
‫création de Node. js complètement

193
00:08:47,580 --> 00:08:49,050
‫différent des autres plateformes.

194
00:08:49,050 --> 00:08:51,600
‫Il prend en charge tous les événements

195
00:08:51,600 --> 00:08:55,120
‫entrants et effectue l'orchestration en déchargeant les tâches les plus lourdes dans

196
00:08:55,120 --> 00:08:58,840
‫le pool de threads et en effectuant lui-même le travail le plus simple.

197
00:08:58,840 --> 00:09:01,520
‫N'oubliez pas non plus que nous avons besoin de

198
00:09:01,520 --> 00:09:05,260
‫la boucle d'événement car dans Node. js tout fonctionne dans un

199
00:09:05,260 --> 00:09:07,260
‫seul thread, et ainsi, vous pouvez avoir

200
00:09:07,260 --> 00:09:11,230
‫des milliers ou des millions d'utilisateurs accédant au même thread en même temps.

201
00:09:11,230 --> 00:09:13,690
‫Cela rend Node si léger et évolutif,

202
00:09:13,690 --> 00:09:16,290
‫mais en même temps, cela présente le danger

203
00:09:16,290 --> 00:09:17,930
‫de bloquer notre

204
00:09:17,930 --> 00:09:20,140
‫thread unique, ce qui ralentirait l'ensemble

205
00:09:20,140 --> 00:09:25,140
‫de l'application ou même s'arrêterait pour tous vos utilisateurs accédant à l'application, n'est-ce pas ?

206
00:09:25,340 --> 00:09:28,110
‫Désormais, dans d'autres langages comme PHP exécutés sur

207
00:09:28,110 --> 00:09:31,300
‫un serveur Apache, en gros, un nouveau thread est créé

208
00:09:31,300 --> 00:09:35,200
‫pour chaque nouvel utilisateur, ce qui est beaucoup plus gourmand en ressources.

209
00:09:35,200 --> 00:09:37,180
‫Mais d'un autre côté, il n'y a

210
00:09:37,180 --> 00:09:39,160
‫aucun danger de blocage, non ?

211
00:09:39,160 --> 00:09:41,430
‫Donc, tout ce modèle facilite un peu

212
00:09:41,430 --> 00:09:44,340
‫l'utilisation de PHP pour les débutants, mais bien sûr, il

213
00:09:44,340 --> 00:09:46,540
‫a ses propres inconvénients, sur lesquels

214
00:09:46,540 --> 00:09:48,890
‫je ne vais pas m'attarder à ce stade.

215
00:09:48,890 --> 00:09:50,690
‫Quoi qu'il en soit, permettez-moi

216
00:09:50,690 --> 00:09:54,860
‫de vous rappeler à nouveau qu'il est de votre responsabilité de ne pas bloquer

217
00:09:54,860 --> 00:09:58,150
‫la boucle d'événement, et voici donc quelques directives à ce sujet.

218
00:09:58,150 --> 00:10:00,490
‫Tout d'abord, n'utilisez pas les versions

219
00:10:00,490 --> 00:10:02,850
‫de synchronisation des fonctions des modules fs,

220
00:10:02,850 --> 00:10:06,450
‫crypto ou zlib dans vos fonctions de rappel, d'accord ?

221
00:10:06,450 --> 00:10:09,210
‫Ainsi, dans notre premier projet, nous avons en fait

222
00:10:09,210 --> 00:10:12,610
‫utilisé la version synchrone, mais c'était dans le code de niveau

223
00:10:12,610 --> 00:10:15,000
‫supérieur, donc en dehors de tout rappel.

224
00:10:15,000 --> 00:10:18,520
‫Et puisque ce code s'exécute avant même que la boucle d'événement ne

225
00:10:18,520 --> 00:10:22,200
‫commence, eh bien, ce n'est pas un problème d'utiliser la version synchrone là-bas.

226
00:10:22,200 --> 00:10:24,910
‫De plus, et c'est probablement assez évident,

227
00:10:24,910 --> 00:10:28,140
‫n'effectuez pas de calculs très complexes dans la boucle d'événements.

228
00:10:28,140 --> 00:10:29,730
‫Donc, des trucs comme croquer

229
00:10:29,730 --> 00:10:33,890
‫des millions de nombres dans des boucles à l'intérieur de boucles, ou quelque chose comme ça.

230
00:10:33,890 --> 00:10:37,550
‫Ensuite, soyez prudent avec JSON dans des objets très volumineux car à

231
00:10:37,550 --> 00:10:40,480
‫un moment donné, l'analyse ou la chaîne de

232
00:10:40,480 --> 00:10:43,440
‫caractères JSON peut commencer à prendre beaucoup de temps.

233
00:10:43,440 --> 00:10:47,170
‫Et enfin, n'utilisez pas d'expressions régulières trop complexes, par exemple,

234
00:10:47,170 --> 00:10:49,840
‫avec plusieurs quantificateurs imbriqués ou références arrière,

235
00:10:49,840 --> 00:10:52,130
‫car encore une fois, elles

236
00:10:52,130 --> 00:10:54,810
‫peuvent prendre plus de temps que prévu.

237
00:10:54,810 --> 00:10:56,680
‫Ce ne sont, bien sûr, que quelques

238
00:10:56,680 --> 00:10:59,700
‫directives de haut niveau, mais elles vous permettront de démarrer sur

239
00:10:59,700 --> 00:11:00,803
‫la bonne voie.

240
00:11:01,650 --> 00:11:03,490
‫Maintenant, il existe des solutions

241
00:11:03,490 --> 00:11:06,390
‫potentielles à ces problèmes de blocage, comme le déchargement manuel

242
00:11:06,390 --> 00:11:09,750
‫vers le pool de threads ou l'utilisation de processus enfants, et

243
00:11:09,750 --> 00:11:12,070
‫nous pourrions en parler d'ici la fin

244
00:11:12,070 --> 00:11:14,370
‫du cours ou dans le futur, mais

245
00:11:14,370 --> 00:11:17,460
‫pour l'instant, il est important que vous comprenez et suivez ce

246
00:11:17,460 --> 00:11:20,110
‫conseil de vraiment ne pas bloquer la boucle d'événement.

247
00:11:20,110 --> 00:11:21,600
‫D'accord.

248
00:11:21,600 --> 00:11:24,520
‫Ensuite, je vais vous donner un petit exemple pour vous montrer

249
00:11:24,520 --> 00:11:25,990
‫certaines des choses dont

250
00:11:25,990 --> 00:11:27,640
‫nous avons parlé dans la pratique.