07
Javascriptでカプセル化のコスト
Filed Under (article, level☆☆☆☆) by on 07-02-2008
Javascriptでカプセル化を実現する！の続編みたいなものです。
この記事を投稿したところ、chokodogさんから次のような指摘を受けました。
（コメントありがとうございます＞＜）
カプセル化した場合、コンストラクタ内でメソッドが定義されているので、new するたびfunctionが定義され、prototypeで定義するよりメモリを多くとられてしまうということはないのでしょうか？
たしかにそのとおりです。
今回はカプセル化を先のような方法で行うとどのようなコストがかかるのかということ探ってみました。
メモリを使うのでは？ってどういうこと？
chokodogさんの指摘の意味を簡単に説明したいと思います。
まずは以下のjavascriptのプログラムを見てください。
-
//オブジェクトのプロトタイププロパティを設定
-
Object.prototype.objprop=100;
-
//Classオブジェクトの作成
-
var Class=function(){};
-
//Classのインスタンスオブジェクトの作成
-
var instance=new Class();
-
//Classプロトタイププロパティを設定
-
Class.prototype.classprop=200;
-
//instanceの
-
instance.insprop=300;
-
-
-
log(instance.objprop);
-
//-->100
-
log(instance.classprop);
-
//-->200
-
log(instance.insprop);
-
//-->300
-
log(instance.hasOwnProperty("objprop"));
-
//->false
-
log(instance.hasOwnProperty("classprop"));
-
//->false
-
log(instance.hasOwnProperty("insprop"));
-
//->false
-
/*
-
ここでinstanceのプロトタイプチェーンをたどって
-
みつかったプロパティをOwnプロパティとして設定
-
*/
-
instance.objprop=instance.objprop;
-
instance.classprop=instance.classprop;
-
-
log(instance.hasOwnProperty("objprop"));
-
// -->true
-
log(instance.hasOwnProperty("classprop"));
-
// -->true
-
log(instance.hasOwnProperty("insprop"));
-
// -->true
JavaScriptは通常のクラスベースのオブジェクト指向とことなりプロトタイプベースという別のプログラムパラダイムを採用しています。
JavaScriptのオブジェクトはすべてハッシュのようなものになっていますが、これに少しばかり細工がしてあります。
それがプロトタイプチェーンというやつです。
オブジェクトは、自身のプロパティで見つからないようなハッシュ値を自分自身のコンストラクタのプロトタイプへと探しにいきます。
たとえば、上のプログラムの場合、
objpropというプロパティを探しにいったときに
・自分自身のプロパティではない
・自分のコンストラクタのプロトタイププロパティではない。
・チェーンの終端であるオブジェクトのプロトタイププロパティで発見
というような順番で探っています。
しかし、次のようにするとプロトタイプ経由のプロパティを自分自身のプロパティとして利用することができます。
-
/*
-
ここでinstanceのプロトタイプチェーンをたどって
-
みつかったプロパティをOwnプロパティとして設定
-
*/
-
instance.objprop=instance.objprop;
-
instance.classprop=instance.classprop;
-
-
log(instance.hasOwnProperty("objprop"));
-
// -->true
-
log(instance.hasOwnProperty("classprop"));
-
// -->true
-
log(instance.hasOwnProperty("insprop"));
-
// -->true
さて、プロトタイプチェーンの仕組みを踏まえて
次のようなプログラムを見てください。
-
/*
-
プロトタイプとしてメソッドを実装
-
*/
-
Object.prototype.test=function(){alert(”hello”)};
-
var t1={val:2};
-
var t2={val:1};
-
-
// ===で同一のリファレンスか確認
-
console.log(t1.test===t2.test);//true
-
-
/*
-
instanceのown propertyとして実装
-
*/
-
var Class=function(){
-
this.test=function(){alert(”hello!”);}
-
}
-
var c1=new Class();
-
var c2=new Class();
-
-
//こちらは別のリファレンスになってしまう。
-
console.log(c1.test===c2.test);//false
このように、オブジェクトのメソッドを定義する際に、
オウンプロパティとして実装する場合では、
２つのインスタンスの定義した関数のそれぞれのさすリファレンスがことなることがわかります。
リファレンスとはC言語でいえばポインタ。
つまりコンピュータのメモリ上の格納場所が異なるということです。
なので、
カプセル化した場合、コンストラクタ内でメソッドが定義されているので、new するたびfunctionが定義され、prototypeで定義するよりメモリを多くとられてしまうということはないのでしょうか？
冒頭のこのようなコメントを頂戴するわけです。
このコメントに対して、僕はあろうことか鼻くそほじるように
「トレードオフじゃないですか～。サーセンｗｗフヒヒ」(嘘おおげさ紛らわしい)と答えてしまいました。
やっぱりどのくらいコストがかかるのか確かめてみようと思い、実験を行いました。
実験内容
二つのjavascriptプログラムの実行時間とメモリ消費量を調べる。
-
/*
-
アンダーバー記法のクラス
-
*/
-
//人間を作るときの関数（コンストラクタ）
-
var Human=function(name,year){
-
this._year=year;
-
this.name=name;
-
this._checkEto();
-
};
-
//人間のDNA（設計図）を決める
-
Human.prototype={
-
name:"",_year:1983,_eto:"亥",
-
//干支を生まれ年から計算する
-
_checkEto:function(){
-
this._eto=["子","丑","寅",
-
"卯","辰","巳",
-
"午","未","申",
-
"酉","戌","亥"][(this._year-4)%12];
-
},
-
//年齢を決める。
-
setYear:function(year){
-
this._year=year;
-
this._checkEto();
-
},
-
getYear:function(){return this._year;},
-
getEto:function(){return this._eto;}
-
};
-
/*
-
クロージャによるカプセル化クラス
-
*/
-
var Human=(function(){
-
var constructor=function(name,year){
-
var inner={
-
name:name,
-
eto:"",
-
year:year,
-
/*
-
private
-
*/
-
checkEto:function(){
-
inner.eto=["子","丑","寅",
-
"卯","辰","巳",
-
"午","未","申",
-
"酉","戌","亥"][(inner.year-4)%12];
-
}
-
};
-
inner.checkEto();
-
-
this.setName=function(name){
-
inner.name=name;
-
-
};
-
this.setYear=function(year){
-
inner.year=year;
-
inner.checkEto();
-
};
-
this.getName=function(){
-
return inner.name;
-
};
-
this.getYear=function(){
-
return inner.year;
-
};
-
this.getEto=function(){
-
return inner.eto;
-
};
-
}
-
-
return constructor;
-
})();
この２つのプログラムの生成にかかるコストをこのような
プログラムをそれぞれに行い調査します。
-
for(var i=0;i<10000;i++){
-
var x=new Human("DAICHI"+i,i);
-
}
実行時間
# time js none.js real 0m0.006s # time js cap.js real 0m0.007s # time js underbar.js real 0m0.007s # time js c_cap_10000.js real 0m1.741s # time js c_underbar_10000.js real 0m0.867s
jsインタプリタにはspidermonkeyを使います。
none.jsはただjsインタプリタを起動するのにかかった時間をはかるために何も書いていないjsファイルをtouchして作っただけです。
読み込みにはそれぞれ0.001secしかかかっていません。
実行時間は10000個のインスタンス生成におよそ0.874秒のコストがかかっています。
ということは、カプセルかによって
87.4マイクロ秒
のコストが１つのインスタンス生成あたりにかかっているようです。
メモリ消費量について
次はメモリの消費量です。
これは昨日作ったfleafeedを使ってみます。
C言語でメモリ使用量をカウントする！
timeコマンドのオプション使えやって思った人は正しいんですが、
せっかくなので使ってみたくなっちゃったんだもん＞＜
#fleafeed js none.js < fleafeed > -----------fleafeed results------------ --USING HEAP : 48574 bytes #fleafeed js cap.js -----------fleafeed results------------ --USING HEAP : 59641 bytes # fleafeed js underbar.js -----------fleafeed results------------ --USING HEAP : 56019 bytes # fleafeed js c_cap_10000.js -----------fleafeed results------------ --USING HEAP :12925508 bytes # fleafeed js c_underbar_10000.js -----------fleafeed results------------ --USING HEAP : 1731685 bytes
とこんな感じ。
jsの実装はほとんどHEAPしか使わないので、HEAP領域のみをピックアップしてみました。
まず、読み込みにかかるコストの比較ですが
アンダーライン記法：11067 bytes クロージャ記法 ：7745 bytes
あれ？なんかしらんけどクロージャ記法のほうが読み込みは少ないっぽいです。不思議。
次に生成１つあたりのメモリコストの違いですが
これはでかいですね。
これを計算してみると１つあたりのメモリコストは
1,110 bytes
となっているようです。およそ1kのメモリが余分に使われてしまうわけです。
これは確かにコスト高な感じはします。
富豪プログラミングをしたいひとにはオススメということで
どうでしょうか（泣）