1
00:00:02,210 --> 00:00:07,780
Now one thing which also costs performance but it just is what it is in this app is the fact that we

2
00:00:07,870 --> 00:00:14,810
unshift the array because as you learned in the Arrays and Iterables section, this simply means that Javascript

3
00:00:14,810 --> 00:00:20,960
has to revisit all array elements and push them all to the end of the array because we add a

4
00:00:20,960 --> 00:00:22,460
new element at the very beginning,

5
00:00:22,550 --> 00:00:26,120
so all elements have to be moved but it is just what it is,

6
00:00:26,120 --> 00:00:30,920
if that is what we want to do in this app, well it is what we want to do and that's the part where you

7
00:00:30,920 --> 00:00:34,130
should be careful when you try to optimize everything.

8
00:00:34,130 --> 00:00:40,910
It's easy to think in a super complex way and try to optimize things which really don't need optimization.

9
00:00:40,910 --> 00:00:48,770
Sure, using unshift is slower than using push but unless you're doing this every second on an array

10
00:00:48,860 --> 00:00:56,220
with thousands of items, you probably won't notice a difference because when we talk about performance,

11
00:00:56,300 --> 00:01:00,980
sure we might have a difference of let's say 10 milliseconds but will this matter?

12
00:01:00,980 --> 00:01:01,360
No,

13
00:01:01,400 --> 00:01:02,810
this will not matter.

14
00:01:03,020 --> 00:01:06,470
So you should be careful when you try to optimize everything,

15
00:01:06,470 --> 00:01:12,290
it's often not worth it and you might even break your app or come up with some strange workaround which

16
00:01:12,410 --> 00:01:17,360
offers a bad user experience or which in the worst case is even slower

17
00:01:17,360 --> 00:01:23,510
just because you try to avoid a certain way of doing something which just turns to be out the right

18
00:01:23,510 --> 00:01:27,890
way even though it technically is slower than some other way.

19
00:01:27,890 --> 00:01:31,560
Let's dive a bit deeper into these micro optimizations though,

20
00:01:31,610 --> 00:01:34,810
i told you that you should measure before you optimize. Now

21
00:01:34,820 --> 00:01:40,400
thus far we haven't done too much measurement because the optimizations we did, mostly those regarding

22
00:01:40,400 --> 00:01:43,790
the DOM are no-brainers, they are better,

23
00:01:43,790 --> 00:01:49,300
they're also not micro optimizations, these are really optimizations which can matter.

24
00:01:49,370 --> 00:01:55,570
Now here's an example for a micro optimization where we want to check if it's better. In rendering.js, in

25
00:01:55,580 --> 00:01:58,510
render products here,

26
00:01:58,650 --> 00:02:00,030
I'm using for each.

27
00:02:00,420 --> 00:02:05,220
Now this is not the only way of going through all items in an array as you know,

28
00:02:05,340 --> 00:02:13,050
so let's find out if it's the best one. For that, let's log a start time with performance.now which

29
00:02:13,050 --> 00:02:16,010
is a function that helps you measure performance,

30
00:02:16,020 --> 00:02:19,670
it gives you a timestamp in the end. Then here we have the

31
00:02:22,590 --> 00:02:25,400
end time which is also performance.now

32
00:02:25,410 --> 00:02:33,210
which executes after for each and then we can console log end time minus start time

33
00:02:33,210 --> 00:02:37,230
to get the time difference.

34
00:02:37,290 --> 00:02:40,340
Now let's save that and let's see what the time difference is.

35
00:02:41,540 --> 00:02:47,100
Open the console here and you see here it logs around .33

36
00:02:48,200 --> 00:02:54,410
and if we reload here multiple times, we see there are quite some differences which already shows you

37
00:02:54,410 --> 00:02:57,500
that you have to be careful regarding such optimizations,

38
00:02:57,500 --> 00:03:03,260
you would want to run this a couple of thousand times by writing some extra script which just refreshes

39
00:03:03,260 --> 00:03:06,620
this or executes your script to find out what is better.

40
00:03:07,100 --> 00:03:14,570
So here we see we have a couple of different numbers but we're somewhere around 30-ish but really there

41
00:03:14,570 --> 00:03:19,900
is a lot of deviation. Now let's try a different approach,

42
00:03:19,940 --> 00:03:26,470
let's comment out this approach and instead let's use a regular for loop, not even a for/of loop,

43
00:03:26,530 --> 00:03:33,800
a very traditional for loop where we have i which starts at zero, where we then loop as long as i is

44
00:03:33,800 --> 00:03:38,790
smaller as products.length, where then increment i by 1.

45
00:03:38,930 --> 00:03:42,010
And now let's grab this code here, put it in here

46
00:03:43,550 --> 00:03:47,730
and here of course, we have to access products for index

47
00:03:47,750 --> 00:03:56,320
i and here, it's also products i and yes that should be it.

48
00:03:56,330 --> 00:03:58,480
Now let's save this.

49
00:03:58,520 --> 00:04:05,920
Now when you execute this a couple of times, you most likely will not see a significant difference,

50
00:04:06,110 --> 00:04:09,080
you might see some results which are faster,

51
00:04:09,080 --> 00:04:13,720
you might see less results which are on the higher end as we saw it before

52
00:04:14,120 --> 00:04:16,340
but there really is also a lot of randomness involved,

53
00:04:16,370 --> 00:04:19,570
as I said you would need to run this tens of thousands of times.

54
00:04:19,610 --> 00:04:25,440
Well turns out there are pages which do this for you, jsperf.com is such a site.

55
00:04:25,520 --> 00:04:30,590
Now you need to log in with a github account here to create your own test cases which in the end are comparisons

56
00:04:30,590 --> 00:04:32,090
of different approaches

57
00:04:32,090 --> 00:04:37,800
but you can also go to the popular test cases down here to find comparisons

58
00:04:37,800 --> 00:04:41,730
other people ran and here I'm talking about Javascript code comparisons.

59
00:04:41,730 --> 00:04:45,150
For example here we have a comparison of for and for each

60
00:04:45,150 --> 00:04:50,180
and you see a lot of other comparisons down there as well.

61
00:04:50,200 --> 00:04:55,750
Now this here is in the end of benchmark which in the end has an array with bunch of numbers as you can

62
00:04:55,750 --> 00:04:56,080
tell

63
00:04:56,680 --> 00:05:02,020
and then these different tests are being run, it tests going through all these items with a for loop,

64
00:05:03,020 --> 00:05:09,500
with a for/of loop, with the for each function and also with the reduce function.

65
00:05:09,510 --> 00:05:15,870
Now let's click on run tests and now it runs these tests for a couple of times and then it gives you

66
00:05:15,870 --> 00:05:16,530
an average,

67
00:05:16,530 --> 00:05:22,140
So let's wait for this to finish and what you should see and the exact results will differ,

68
00:05:22,140 --> 00:05:27,330
you can also run this for multiple times but what you should see is that the traditional for loop actually

69
00:05:27,330 --> 00:05:33,720
is fastest and if you google that, if you google for versus for/of Javascript and so on, you will find

70
00:05:33,720 --> 00:05:36,460
a lot of discussions where this is also discussed.

71
00:05:36,720 --> 00:05:42,900
Indeed right now at least, the traditional for loop is faster than the for/of loop is faster than

72
00:05:42,900 --> 00:05:45,260
for each and so on.

73
00:05:45,270 --> 00:05:50,730
Now does this mean you should switch and replace all for/of loops with this loop?

74
00:05:50,730 --> 00:05:52,710
Why did I even teach you for/of

75
00:05:52,740 --> 00:06:00,420
if it's slower? Because when we talk about it being slow here, we have to be really careful. When

76
00:06:00,420 --> 00:06:05,340
we talk about a difference, like here in my browser of 11%,

77
00:06:05,340 --> 00:06:06,690
that's not a lot,

78
00:06:06,690 --> 00:06:12,900
you might not be running across an array with that thousands of items multiple times every second, if

79
00:06:12,900 --> 00:06:13,880
you do that,

80
00:06:13,920 --> 00:06:16,680
the difference might matter. Most of the time,

81
00:06:16,710 --> 00:06:22,200
99% of all applications, you're not going to do that because if you would do that, even

82
00:06:22,200 --> 00:06:26,240
with the fastest approach, it would probably be slow at some point.

83
00:06:26,250 --> 00:06:33,030
So when we talk about differences here, we really have to be careful that we don't go for the fastest

84
00:06:33,030 --> 00:06:39,030
result just because it shows it here and totally forget that this doesn't matter

85
00:06:39,030 --> 00:06:46,370
in most cases. So when you're comparing results, if you're benchmarking and you're checking whether approach

86
00:06:46,450 --> 00:06:52,610
A is faster than approach B, for example with benchmarking web sites like jsperf.com, you have

87
00:06:52,610 --> 00:06:58,310
to interpret the results with caution because of what I just said that you might not be running thousands

88
00:06:58,310 --> 00:07:02,820
of operations and the performance difference therefore really will not make a difference

89
00:07:02,930 --> 00:07:07,610
and then you should go for the code which is more readable and shorter and not for the most complex

90
00:07:07,610 --> 00:07:10,830
code which theoretically might run a bit faster

91
00:07:10,970 --> 00:07:16,630
and in addition, keep in mind that performance is not a fixed thing.

92
00:07:16,700 --> 00:07:19,420
It might differ from browser to browser,

93
00:07:19,430 --> 00:07:23,210
thus far we only tested in Chrome, in Firefox it might be a bit different

94
00:07:23,480 --> 00:07:29,930
and it will change over time. Of course if approach A is slower than B at the moment,

95
00:07:29,930 --> 00:07:37,430
this does not mean it's slower in a year or in six months especially the newer Javascript engine features

96
00:07:37,670 --> 00:07:45,170
which were added one or two years ago will most likely become faster over time and they might overtake

97
00:07:45,440 --> 00:07:48,070
the existing, the older approaches then.

98
00:07:48,110 --> 00:07:55,370
So of course you can then always go back to your code and reimplement it with the then best approach or

99
00:07:55,370 --> 00:07:55,580
you

100
00:07:55,580 --> 00:08:01,400
keep in mind that you're not running this operation thousands of times and therefore this micro optimization

101
00:08:01,670 --> 00:08:04,050
really doesn't matter.

102
00:08:04,070 --> 00:08:09,010
So back in our code, this means we can of course run this loop like this

103
00:08:09,020 --> 00:08:10,250
and it's nice to do that,

104
00:08:10,250 --> 00:08:16,790
it's also good to know how you can measure performance with performance.now but you shouldn't overdo

105
00:08:16,790 --> 00:08:19,190
it and here, because it's a bit shorter,

106
00:08:19,190 --> 00:08:24,580
I will go back to my old for each approach which isn't horrible, which is a bit slower

107
00:08:24,590 --> 00:08:30,920
but again we won't really feel that here and therefore, this is the approach I will use here and that is

108
00:08:30,920 --> 00:08:37,040
what you should keep in mind about benchmarking and micro optimizations like this one, where you try

109
00:08:37,040 --> 00:08:43,340
to optimize everything and you might therefore end up with longer or less readable code or an approach

110
00:08:43,340 --> 00:08:47,060
which isn't the best anymore in a year or half a year.