forked from judos/beltSorter
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTestCase time measurements.txt
65 lines (54 loc) · 2.3 KB
/
TestCase time measurements.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Description
2 test cases for performence measurements:
- T1: 473 belt-sorters (11 doing some item distribution with connected belts and filter)
belt-sorters are not connected
belt-sorter have no filter
30 UPS (old state)
60 UPS (new)
- T2: 176 belt-sorters (all of them distributing items north 1 lane)
belt-sorters have 3 connected belts, 1 input, 1 output, 1 idle
belt-sorters have 1 item filter to put items north
40 UPS (old state)
60 UPS (new)
-------------------------------------------------------
OLD VERSION 0.3.10
-------------------------------------------------------
T1: ~140ms update time -> ~0.3ms / belt-sorter
T2: ~65ms update time -> ~0.37ms / belt-sorter
-------------------------------------------------------
FIRST STEP: measure different times of method:
-------------------------------------------------------
T1 idle taking apart: ~percentage
25ms input/output search 15%
135ms filter building 82%
0ms item distribution 0%
5ms scheduling 3%
165ms total
T2 working taken apart: ~percentage
35ms input/output search 39%
50ms filter building 56%
2ms item distribution 2%
2ms scheduling 2%
89ms total
-------------------------------------------------------
SECOND STEP: target improvements
-------------------------------------------------------
1. building up the belt-sorter filter takes most time
a) improve the code: T1:140ms->75ms, T2:50ms->35ms
b*) calculate filter only every 2-5s ? (Don't measure this since it's just spreading the work)
2. input/output search takes also 40% time (especially for belt sorters connected with several belts
a) improve how it's done
b*) only recalculate every 5s or when a belt is invalid (don't measure)
-------------------------------------------------------
THIRD STEP: improvements
-------------------------------------------------------
1. new custom gui developed for belt-sorter.
building the filter for the belt-sorter is done when gui is accessed, afterwards it's never needed
2. input/output search: rotate the calculation, only one side per update
T1: 25ms -> 9ms
T2: 35ms -> ~9ms (avg)
-------------------------------------------------------
FINAL: results
-------------------------------------------------------
T1: 165ms total -> 12ms total
T2: 89ms total -> 10ms total