回答編集履歴

6

誤解を招く表現があった

2018/07/31 16:05

投稿

toritoritorina
toritoritorina

スコア972

test CHANGED
@@ -54,8 +54,6 @@
54
54
 
55
55
  全体の3分の1ぐらいをmulchProcess関数で費やしています。
56
56
 
57
- changeToGray関数は、時間のかかった処理トップ10には入らないようです。
58
-
59
57
  ```
60
58
 
61
59
  33640 function calls (33601 primitive calls) in 0.139 seconds

5

見やすく

2018/07/31 16:05

投稿

toritoritorina
toritoritorina

スコア972

test CHANGED
@@ -98,7 +98,7 @@
98
98
 
99
99
 
100
100
 
101
-
101
+  
102
102
 
103
103
  python main.py a.jpg 8
104
104
 
@@ -142,7 +142,7 @@
142
142
 
143
143
  ```
144
144
 
145
-
145
+  
146
146
 
147
147
  python main.py a.jpg 16
148
148
 
@@ -186,7 +186,7 @@
186
186
 
187
187
  ```
188
188
 
189
-
189
+  
190
190
 
191
191
  極端な例ですが、python main.py a.jpg 500 で実行すると、以下のようになります。
192
192
 

4

追記

2018/07/31 16:00

投稿

toritoritorina
toritoritorina

スコア972

test CHANGED
@@ -54,6 +54,8 @@
54
54
 
55
55
  全体の3分の1ぐらいをmulchProcess関数で費やしています。
56
56
 
57
+ changeToGray関数は、時間のかかった処理トップ10には入らないようです。
58
+
57
59
  ```
58
60
 
59
61
  33640 function calls (33601 primitive calls) in 0.139 seconds

3

微調整

2018/07/31 15:57

投稿

toritoritorina
toritoritorina

スコア972

test CHANGED
@@ -4,7 +4,7 @@
4
4
 
5
5
 
6
6
 
7
- 環境にもよると思いますが、cProfileを使いプログラムのどこで時間がかかっているか探しました。
7
+ cProfileを使いプログラムのどこで時間がかかっているか探しました。多分どの環境でも概ね似た結果になると思います。
8
8
 
9
9
  ```python
10
10
 

2

サンプルが不適切だったので、8や16も追加しました。

2018/07/31 15:55

投稿

toritoritorina
toritoritorina

スコア972

test CHANGED
@@ -96,15 +96,99 @@
96
96
 
97
97
 
98
98
 
99
+
100
+
99
-  
101
+ python main.py a.jpg 8
102
+
100
-
103
+ このあたりから、{built-in method posix.fork}等が上位に食い込みます。
104
+
101
-  
105
+ ```
106
+
102
-
107
+ 33592 function calls (33553 primitive calls) in 0.165 seconds
108
+
109
+
110
+
111
+ Ordered by: internal time
112
+
113
+ List reduced from 291 to 10 due to restriction <10>
114
+
115
+
116
+
117
+ ncalls tottime percall cumtime percall filename:lineno(function)
118
+
119
+ 1860 0.097 0.000 0.097 0.000 {method 'acquire' of '_thread.lock' objects}
120
+
121
+ 1 0.026 0.026 0.164 0.164 main.py:49(mulchProcess)
122
+
123
+ 8 0.008 0.001 0.008 0.001 {built-in method posix.fork}
124
+
125
+ 423 0.002 0.000 0.103 0.000 _base.py:196(as_completed)
126
+
127
+ 819 0.002 0.000 0.003 0.000 _base.py:174(_yield_finished_futures)
128
+
129
+ 359 0.002 0.000 0.094 0.000 threading.py:264(wait)
130
+
131
+ 844 0.002 0.000 0.003 0.000 _base.py:405(result)
132
+
133
+ 422 0.001 0.000 0.021 0.000 process.py:596(submit)
134
+
135
+ 397 0.001 0.000 0.096 0.000 threading.py:534(wait)
136
+
137
+ 423 0.001 0.000 0.001 0.000 {built-in method posix.write}
138
+
139
+
140
+
141
+ ```
142
+
143
+
144
+
145
+ python main.py a.jpg 16
146
+
147
+ さすがに過剰になってきたのか、{built-in method posix.fork}の割合がはっきりと増えます。
148
+
149
+ ```
150
+
151
+ 32700 function calls (32661 primitive calls) in 0.208 seconds
152
+
153
+
154
+
155
+ Ordered by: internal time
156
+
157
+ List reduced from 291 to 10 due to restriction <10>
158
+
159
+
160
+
161
+ ncalls tottime percall cumtime percall filename:lineno(function)
162
+
163
+ 1540 0.111 0.000 0.111 0.000 {method 'acquire' of '_thread.lock' objects}
164
+
165
+ 1 0.042 0.042 0.207 0.207 main.py:49(mulchProcess)
166
+
167
+ 16 0.017 0.001 0.017 0.001 {built-in method posix.fork}
168
+
169
+ 423 0.003 0.000 0.110 0.000 _base.py:196(as_completed)
170
+
171
+ 422 0.002 0.000 0.035 0.000 process.py:596(submit)
172
+
173
+ 777 0.002 0.000 0.003 0.000 _base.py:174(_yield_finished_futures)
174
+
175
+ 844 0.002 0.000 0.003 0.000 _base.py:405(result)
176
+
177
+ 279 0.001 0.000 0.102 0.000 threading.py:264(wait)
178
+
179
+ 423 0.001 0.000 0.001 0.000 {built-in method posix.write}
180
+
181
+ 355 0.001 0.000 0.104 0.000 threading.py:534(wait)
182
+
183
+
184
+
185
+ ```
186
+
187
+
188
+
103
- python main.py a.jpg 500 で実行すると、以下のようになります。
189
+ 極端な例ですが、python main.py a.jpg 500 で実行すると、以下のようになります。
104
-
105
- 3.206秒のうち、さきほど半分近くを占めていた{method 'acquire' of '_thread.lock' objects}は4分の1程度です。mulchProcess関数にいたっては、もっと締める割合は小さくなっています。
190
+
106
-
107
- かわ増えたかというと{built-in method posix.fork}や{built-in method posix.waitpid}といったプロセスの操作に関する処理です。単純にプロセス増えで、処理や管理時間がかかっているのではいでしょうか
191
+ ここまでくるとこプログラムに限らず遅くはなますが、プロセス関連の処理がボトルネックになります
108
192
 
109
193
  ```
110
194
 

1

追記

2018/07/31 15:47

投稿

toritoritorina
toritoritorina

スコア972

test CHANGED
@@ -1,8 +1,10 @@
1
1
  だいたいおっしゃるとおりだと思います。
2
+
3
+ changeToGray関数は現状非常に高速で、増やしたコア数の管理のほうが手間になっているのではないでしょうか。
2
4
 
3
5
 
4
6
 
5
- cProfileを使いプログラムのどこで時間がかかっているか探しました。
7
+ 環境にもよると思いますが、cProfileを使いプログラムのどこで時間がかかっているか探しました。
6
8
 
7
9
  ```python
8
10