入手から丸3ヶ月経ったところで、前回(Retina MacBookを使い始めて2ヶ月近く経ったので実用性などをまとめてみた)からの差分です。重めの開発系作業をほとんど捨てる想定でMacBookを買ったのですが、結果いろいろあって日々プログラミングに使っています。圧倒的CPU不足というほどCPUが遅いわけでもないので、「中途半端になんとかなる」のがイマイチです。こういう状態だと、各所の微妙な遅さの影響が最終的にとても大きく効いてきます。意識して日々の作業ボトルネック解消に努める必要があります。
今回はMacBookを使った日々のプログラミング作業を効率化するためのtipsをいくつか紹介します。まあ、あれこれ言いつつ単なる今月のMacBook日記です。
エミュレータ起動後、内部の初期化が一段落ついたタイミングでのCPU消費は図1のようになります。
何もしていない状態でも22%を切ることはほぼありません。CPU消費の主要部分はVirtualBox側でおこなわれているので、Xamarin Android Playerのウィンドウが背後に回っていても特に軽くはなりません。この状態で、MacBook自体も徐々に熱をもっていきます。夏には辛い感じだし、バッテリ稼働時間も縮むのでイマイチです。
あるとき、しばらくCPU消費状況をボーっと眺めて、「これ、Live Wall Paper(ライブ壁紙)のアニメーションをCPUでひたすら頑張って重いのでは?」と思いました。そこで、壁紙の設定を図2のように変えてみると、
見事にスタンバイ時のCPU消費率が2.8%程度まで下がりました(図3)*1。これで日常的に使っていると、明らかに発熱が少ないのを感じます。
そういうわけでMac上では通常boot2dockerを使ってVirtualBoxベースの仮想マシン上にDockerホストを持ちます。
しかしこのVirtualBox、ホスト側とのディレクトリ共有におけるI/O性能が今ひとつ高くありません。
ここで登場するのがdocker-machine+VMware Fusionです。docker-machine自体はboot2dockerの派生物のようですが、様々な面で強化されています。VMware Fusionとの連携サポートもそのひとつで、dockerの--volume(-v)オプションを使ってホストマシンとDockerホストとのデータ共有を簡単におこなえます。
VMware Fusion本体部分のCPU利用効率の良さ*2に加えて、VMware Fusionの共有ディレクトリもそこそこ高速です。手元での多少極端な例ですが、1回のプログラム実行で1,000ほどのファイルを読み込むケースがあるものでの動作速度が20倍ぐらい速くなりました。このように、VMware Fusionの利用はCPUの非力なMacBookでもパフォーマンスの底上げと消費電力低減(=バッテリ持ちの改善)に役立ちます*3。
もちろんVMware Fusionは有償のプロダクトなので、コスト負担するか否かという選択があります。私の場合は、以前利用していたMacBook Proでの作業用に購入したライセンスが宙に浮いていたので、これを活用しました。
おまけとして、boot2dockerとdocker-machineでの簡単なコマンド対応付けを記載します。ここではdocker-machineで作成するVMの名前をdevとしています。
docker-machineは複数のDockerホストを管理する前提で作られているので、管理下のDockerホスト一覧機能などもあります。
という感じです。管理下のDockerホスト同士でファイルをscpする仕組みなどもあって、なかなか面白いのですがまだあまり使っていません。Docker Hub無しでdocker buildコマンドに食わせる設定データをやり取りしたい場合などに便利そうですね。
これは、前回のポエムを書いた後で@vvakameが教えてくれました(一応前回のポエムに追記もしました)。
今のところ、手近なDockerマシンにソース差分をrsyncしてGradleを叩くぐらいが無難かなーという感じがしています。
今回はMacBookを使った日々のプログラミング作業を効率化するためのtipsをいくつか紹介します。まあ、あれこれ言いつつ単なる今月のMacBook日記です。
Xamarin Android Playerの壁紙を変えてCPU消費を手軽に低減する
Androidアプリの開発にあたっては、Xamarin Android Playerが割と良いスピードで動くため、好んで使っています。しかし、これなかなか重量級です。速いといっているのに重いとはどういうことか、という感じですが、要はスタンバイ状態でのCPU消費が激しいのです。エミュレータ起動後、内部の初期化が一段落ついたタイミングでのCPU消費は図1のようになります。
図1 Xamarin Android Playerのスタンバイ時CPU消費
あるとき、しばらくCPU消費状況をボーっと眺めて、「これ、Live Wall Paper(ライブ壁紙)のアニメーションをCPUでひたすら頑張って重いのでは?」と思いました。そこで、壁紙の設定を図2のように変えてみると、
図2 Xamarin Android Playerに壁紙を設定する
図3 Xamarin Android Playerにライブでない壁紙を設定した
[*1] アクティビティモニタ上で2つのVBoxHeadlessがみえるのは、Xamarin Android PlayerのものとDocker用のものです。Docker用のものはスタンバイ時CPU消費率が安定しているので、切り分けて考えました。
Docker利用にはdocker-machine+VMware Fusionを使う
Web系に限らず、最近はDockerを使うことがとても多いです。遠隔地のサーバ上での利用はもちろんですが、ローカル環境に比較的高速に動作するDocker環境があると便利なシーンもあります。そういうわけでMac上では通常boot2dockerを使ってVirtualBoxベースの仮想マシン上にDockerホストを持ちます。
しかしこのVirtualBox、ホスト側とのディレクトリ共有におけるI/O性能が今ひとつ高くありません。
ここで登場するのがdocker-machine+VMware Fusionです。docker-machine自体はboot2dockerの派生物のようですが、様々な面で強化されています。VMware Fusionとの連携サポートもそのひとつで、dockerの--volume(-v)オプションを使ってホストマシンとDockerホストとのデータ共有を簡単におこなえます。
VMware Fusion本体部分のCPU利用効率の良さ*2に加えて、VMware Fusionの共有ディレクトリもそこそこ高速です。手元での多少極端な例ですが、1回のプログラム実行で1,000ほどのファイルを読み込むケースがあるものでの動作速度が20倍ぐらい速くなりました。このように、VMware Fusionの利用はCPUの非力なMacBookでもパフォーマンスの底上げと消費電力低減(=バッテリ持ちの改善)に役立ちます*3。
もちろんVMware Fusionは有償のプロダクトなので、コスト負担するか否かという選択があります。私の場合は、以前利用していたMacBook Proでの作業用に購入したライセンスが宙に浮いていたので、これを活用しました。
おまけとして、boot2dockerとdocker-machineでの簡単なコマンド対応付けを記載します。ここではdocker-machineで作成するVMの名前をdevとしています。
Dockerホストイメージの作成 $ boot2docker init $ docker-machine create --driver vmwarefusion dev Dockerホストの起動 $ boot2docker up $ docker-machine start dev VM上のDockerホストに割り当てられたIPアドレスのチェック $ boot2docker ip $ docker-machine ip dev dockerコマンドからの接続用シェル変数設定 $ eval "$(boot2docker shellinit)" $ eval "$(docker-machine env dev)" Dockerホストの停止 $ boot2docker down $ docker-machine stop dev
$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM dev vmwarefusion Running tcp://172.16.142.128:2376
[*2] 手元環境でざっくりとアクティビティモニタを眺めた感じでは、VMがスタンバイ状態にある時のCPU利用率がVirtualBoxよりもVMware Fusionのほうが結構低いものでした。
[*3] VirtualBoxベースのboot2dockerを利用していると、Macのスリープを挟んで別のネットワーク環境へ移動後に作業を再開した直後にOS Xを巻き込んでクラッシュする不具合に行き当たることも多かったので、これも乗り換えの強い理由でした。
nodebrewではバイナリ利用オプションを使う
大きめのアプリをソースからインストールする行為は、回数少なければ良いのですが日常的にやるのは避けたほうが良いです。とくに、Node.js/io.jsのアップデートのような頻発作業はバイナリを選ぶのが無難です。$ nodebrew install-binary <インストール対象>
Re:VIEW原稿書きの校正フェーズではAtomのlanguage-review適用を外す
これはプログラミングに直結するものではありませんが、関連作業として記載します。だいたい日本語テキストが500行を超えてくると、Atom+language-reviewの動作速度が結構辛い感じになってきます。校正フェーズはVimでやるとか、ファイル自体を分割するというのも手ですが、そうしづらい事情(例: 迫り来る締め切り)があればひとまず Atomの右下にあるステータスバーからRe:VIEWの指定を外してPlain Textに変えましょう。サクサクになります。language-review自体に、シンタックスハイライトのみをおこなう軽量モードがあるとよさそうですね。C++コードのコンパイルにはccacheを活用する
Clangがあればccacheなんて不要!と思っていた時期があったのですが、大きめのC++プロジェクトを頻繁にビルドする際には、やはり相応に有効です。もちろん、コードのビルドでどっかミスるのではないかという一抹の不安はあるので、いわゆる本番用ビルドには利用しないようにしています。ccache自体についてはあちこちに解説があるのでそちらをあたってください。Android NDKでもばっちり使えます。未解決の課題
Javaコード類のビルドがやたらと遅いのは依然として未解決です。distccあるいはccacheのような仕組みが欲しい…。Mac上のEclipseやIntelliJ IDEAから接続して使える、Android用にも使えるいい感じのJavaリモートビルドの仕組みをご存知の方がいれば教えてください。JRebel for Androidが用途的にはそのへんなのかなぁ。今のところ、手近なDockerマシンにソース差分をrsyncしてGradleを叩くぐらいが無難かなーという感じがしています。
0 件のコメント:
コメントを投稿