iCloud Photo Library (32 ビット) が重たい理由 [パソコン]
個人的な推測なのでそうそう力強くは言えないのですが、
iCloud Photo Library が CPU を使いまくる理由は実装の問題のようです。
UsaMimi というプロセス調査アプリを使って iCloud Phot Library の
Thread の動作状況を調べたのが以下です。
やたら稼働時間の多い Thread があるのが見えます。
ちなみに、この Thread の Stack Dump を見てみたら、以下でした。
なんか、パケット投げて返事を待ってを繰り返してる感が満載。
ちなみに、OneDriveのスレッドダンプはこんな感じでした。
異常に動作過多なスレッドないですよね。普通、こういう実装になると思います。まさにお手本です。
iCloud Photo Library のスレッドの動きは、一見、みんな Waiting になっているように見せながら、ひとり最下層で激しい勢いでパケット投げて返事待つっていう 実装になってる気がします、、、、。
せめて、SendWaitReceivePort の Wait を 60sec とかにしときゃ、こんなにぶん回らずに済んだかもしれないですよね。
念の為、GoogleDriveandSync のスレッドダンプも見てみました。
今日は激しく同期をしていたのでスレッド動作時間の大きいのもいますが、一人だけ極端に多いっていう事にはなってないのが分かると思います。
UNIX系のOS上で開発している Mac用プログラムのプログラマがWindowsに移植するときに、この手の稚拙な実装をするとは思えませんが、出来栄えは稚拙すぎます。
結論から言うと、
iCloud Photo Library は Windows10 上で動作させるのはちょっとどうなの？
という事になる気がします。
Appleのプログラマーの方、頑張ってください。
ちなみに、iCloud Photo Library でぶん回ってるスレッドの「待機理由」でだけ登場する LPC reply notice ってなんだか気になるので、時間があったら調べてみます。
Local Procedure Call かなんかの略なのかな？
コメント 0