回答編集履歴
6
誤解を招く表現があった
answer
CHANGED
|
@@ -26,7 +26,6 @@
|
|
|
26
26
|
python main.py a.jpg 1 で実行すると、以下のようになります。
|
|
27
27
|
0.139秒のうち、大体2分の1を{method 'acquire' of '_thread.lock' objects}
|
|
28
28
|
全体の3分の1ぐらいをmulchProcess関数で費やしています。
|
|
29
|
-
changeToGray関数は、時間のかかった処理トップ10には入らないようです。
|
|
30
29
|
```
|
|
31
30
|
33640 function calls (33601 primitive calls) in 0.139 seconds
|
|
32
31
|
|
5
見やすく
answer
CHANGED
|
@@ -48,7 +48,7 @@
|
|
|
48
48
|
|
|
49
49
|
```
|
|
50
50
|
|
|
51
|
-
|
|
51
|
+
|
|
52
52
|
python main.py a.jpg 8
|
|
53
53
|
このあたりから、{built-in method posix.fork}等が上位に食い込みます。
|
|
54
54
|
```
|
|
@@ -70,7 +70,7 @@
|
|
|
70
70
|
423 0.001 0.000 0.001 0.000 {built-in method posix.write}
|
|
71
71
|
|
|
72
72
|
```
|
|
73
|
-
|
|
73
|
+
|
|
74
74
|
python main.py a.jpg 16
|
|
75
75
|
さすがに過剰になってきたのか、{built-in method posix.fork}の割合がはっきりと増えます。
|
|
76
76
|
```
|
|
@@ -92,7 +92,7 @@
|
|
|
92
92
|
355 0.001 0.000 0.104 0.000 threading.py:534(wait)
|
|
93
93
|
|
|
94
94
|
```
|
|
95
|
-
|
|
95
|
+
|
|
96
96
|
極端な例ですが、python main.py a.jpg 500 で実行すると、以下のようになります。
|
|
97
97
|
ここまでくるとこのプログラムに限らず遅くはなりますが、プロセス関連の処理がやたらとボトルネックになります。
|
|
98
98
|
```
|
4
追記
answer
CHANGED
|
@@ -26,6 +26,7 @@
|
|
|
26
26
|
python main.py a.jpg 1 で実行すると、以下のようになります。
|
|
27
27
|
0.139秒のうち、大体2分の1を{method 'acquire' of '_thread.lock' objects}
|
|
28
28
|
全体の3分の1ぐらいをmulchProcess関数で費やしています。
|
|
29
|
+
changeToGray関数は、時間のかかった処理トップ10には入らないようです。
|
|
29
30
|
```
|
|
30
31
|
33640 function calls (33601 primitive calls) in 0.139 seconds
|
|
31
32
|
|
3
微調整
answer
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
だいたいおっしゃるとおりだと思います。
|
|
2
2
|
changeToGray関数は現状非常に高速で、増やしたコア数の管理のほうが手間になっているのではないでしょうか。
|
|
3
3
|
|
|
4
|
-
|
|
4
|
+
cProfileを使いプログラムのどこで時間がかかっているか探しました。多分どの環境でも概ね似た結果になると思います。
|
|
5
5
|
```python
|
|
6
6
|
if __name__ == '__main__':
|
|
7
7
|
import cProfile
|
2
サンプルが不適切だったので、8や16も追加しました。
answer
CHANGED
|
@@ -47,12 +47,54 @@
|
|
|
47
47
|
|
|
48
48
|
```
|
|
49
49
|
|
|
50
|
-
|
|
51
|
-
|
|
50
|
+
|
|
52
|
-
python main.py a.jpg
|
|
51
|
+
python main.py a.jpg 8
|
|
53
|
-
3.206秒のうち、さきほど半分近くを占めていた{method 'acquire' of '_thread.lock' objects}は4分の1程度です。mulchProcess関数にいたっては、もっと締める割合は小さくなっています。
|
|
54
|
-
|
|
52
|
+
このあたりから、{built-in method posix.fork}等が上位に食い込みます。
|
|
55
53
|
```
|
|
54
|
+
33592 function calls (33553 primitive calls) in 0.165 seconds
|
|
55
|
+
|
|
56
|
+
Ordered by: internal time
|
|
57
|
+
List reduced from 291 to 10 due to restriction <10>
|
|
58
|
+
|
|
59
|
+
ncalls tottime percall cumtime percall filename:lineno(function)
|
|
60
|
+
1860 0.097 0.000 0.097 0.000 {method 'acquire' of '_thread.lock' objects}
|
|
61
|
+
1 0.026 0.026 0.164 0.164 main.py:49(mulchProcess)
|
|
62
|
+
8 0.008 0.001 0.008 0.001 {built-in method posix.fork}
|
|
63
|
+
423 0.002 0.000 0.103 0.000 _base.py:196(as_completed)
|
|
64
|
+
819 0.002 0.000 0.003 0.000 _base.py:174(_yield_finished_futures)
|
|
65
|
+
359 0.002 0.000 0.094 0.000 threading.py:264(wait)
|
|
66
|
+
844 0.002 0.000 0.003 0.000 _base.py:405(result)
|
|
67
|
+
422 0.001 0.000 0.021 0.000 process.py:596(submit)
|
|
68
|
+
397 0.001 0.000 0.096 0.000 threading.py:534(wait)
|
|
69
|
+
423 0.001 0.000 0.001 0.000 {built-in method posix.write}
|
|
70
|
+
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
python main.py a.jpg 16
|
|
74
|
+
さすがに過剰になってきたのか、{built-in method posix.fork}の割合がはっきりと増えます。
|
|
75
|
+
```
|
|
76
|
+
32700 function calls (32661 primitive calls) in 0.208 seconds
|
|
77
|
+
|
|
78
|
+
Ordered by: internal time
|
|
79
|
+
List reduced from 291 to 10 due to restriction <10>
|
|
80
|
+
|
|
81
|
+
ncalls tottime percall cumtime percall filename:lineno(function)
|
|
82
|
+
1540 0.111 0.000 0.111 0.000 {method 'acquire' of '_thread.lock' objects}
|
|
83
|
+
1 0.042 0.042 0.207 0.207 main.py:49(mulchProcess)
|
|
84
|
+
16 0.017 0.001 0.017 0.001 {built-in method posix.fork}
|
|
85
|
+
423 0.003 0.000 0.110 0.000 _base.py:196(as_completed)
|
|
86
|
+
422 0.002 0.000 0.035 0.000 process.py:596(submit)
|
|
87
|
+
777 0.002 0.000 0.003 0.000 _base.py:174(_yield_finished_futures)
|
|
88
|
+
844 0.002 0.000 0.003 0.000 _base.py:405(result)
|
|
89
|
+
279 0.001 0.000 0.102 0.000 threading.py:264(wait)
|
|
90
|
+
423 0.001 0.000 0.001 0.000 {built-in method posix.write}
|
|
91
|
+
355 0.001 0.000 0.104 0.000 threading.py:534(wait)
|
|
92
|
+
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
極端な例ですが、python main.py a.jpg 500 で実行すると、以下のようになります。
|
|
96
|
+
ここまでくるとこのプログラムに限らず遅くはなりますが、プロセス関連の処理がやたらとボトルネックになります。
|
|
97
|
+
```
|
|
56
98
|
301193 function calls (301154 primitive calls) in 3.206 seconds
|
|
57
99
|
|
|
58
100
|
Ordered by: internal time
|
1
追記
answer
CHANGED
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
だいたいおっしゃるとおりだと思います。
|
|
2
|
+
changeToGray関数は現状非常に高速で、増やしたコア数の管理のほうが手間になっているのではないでしょうか。
|
|
2
3
|
|
|
3
|
-
cProfileを使い
|
|
4
|
+
環境にもよると思いますが、cProfileを使いプログラムのどこで時間がかかっているか探しました。
|
|
4
5
|
```python
|
|
5
6
|
if __name__ == '__main__':
|
|
6
7
|
import cProfile
|