アプリケーションオブジェクトの組み込みコレクションには、シンプルなタイプを保存するために設計されたコンテンツがあり、デフォルトアプリケーション（「キー」）を使用できます。
ただし、Application.Contentsはオブジェクトを保存できず、VBSアレイを保存できますが、JavaScriptには配列さえ配置できません。
Application.Contentsを使用する場合、次のような醜いもののみを使用できます。
for（vari = 0; i <15000; i ++）{
Application.Lock（）;
//application.contents(I）="sdfdsffdsaf ";
アプリケーション（i）= "sdfdsffdsaf";
application.unlock（）;}
ここでは、1.5Wの文字列をApplication.Contentsに保存します。
Application.StaticObjectsを使用した後：
StaticObjectは直接アクセスを許可しないため、データを保存するStaticObjectとして辞書を定義します。
<ObjectId = "dict" runat = "server" scope = "application" progid = "scripting.dictionary"> </object>
Scripting.Dictionary自体は非常に高速であり、StaticObjectsの収集速度の比較に大きな影響を与えません。
辞書の速度：
vard = newActiveXObject（ "Scripting.Dictionary"）;
for（vari = 0; i <15000; i ++）{
d.item（i）= "sdfdsffdsaf";}
1.5Wの補間、172ms
もちろん、カスタムオブジェクトvard = newObject（）; d [i] = ..はより高速で、1.5Wは80〜90msしかかかりませんが、機能ははるかに弱いため、辞書を使用します。
以下の公式テストを参照してください
for（vari = 0; i <15000; i ++）{
Application.Lock（）;
application.staticObjects（ "dict"）。item（i）= "sdfdsffdsaf";
application.unlock（）;}
時間は6953msです。当初、StaticObjectsコレクションのアクセス速度がキャッシュの要件を満たすことができないと判断されます。この速度は、AdooledBがSQLSERVER2000を読み取る時とほぼ同じです。
ただし、StaticObjectsの利点はオブジェクトを保存できることであり、辞書はデータだけでなくキャッシュオブジェクトとして使用できる他のオブジェクトも保存できることです。
application.staticObjects（ "dict"）にオブジェクトを入れました：
application.staticObjects（ "dict"）。item（ "o"）= newObject（）;
for（vari = 0; i <15000; i ++）{
Application.Lock（）;
application.staticObjects（ "dict"）。item（ "o"）[i] = "sdfdsffdsaf";
application.unlock（）;}
6656ms、少し速い。オブジェクトのもう1つのレイヤーは、速度を遅くしません。低速は、複雑な構造のためではなく、staticobjectsのアクセス占有によるものです。
プレストアDICTのリファレンス
vart = application.staticObjects（ "dict"）;
for（vari = 0; i <15000; i ++）{
Application.Lock（）;