ASP javascript Application對象的Contents和StaticObjects做Cache的一些經(jīng)驗
更新時間:2008年05月18日 21:35:39 作者:
ASP javascript: Application對象的Contents和StaticObjects做Cache的一些結(jié)論。
ASP封裝Cache對象,一般都是基于Application的,
Application對象內(nèi)置集合有為存放簡單類型設(shè)計的Contents,默認(rèn)Application("key")就可以使用。
不過Application.Contents不能存放對象,可以存vbs數(shù)組,但是在javascript下甚至數(shù)組都不能放。
使用Application.Contents時,只能用丑陋的如:
for(var i=0;i<15000;i++){
Application.Lock();
// Application.Contents(i)="sdfdsffdsaf";
Application(i)="sdfdsffdsaf";
Application.Unlock();}
在這里往Application.Contents存放了1.5w個String,共花費時間234ms.
改用Application.StaticObjects后:
定義一個Dictionary作為StaticObject,用于存放數(shù)據(jù),因為StaticObject是不允許直接訪問的。
<object id="dict" runat="server" scope="Application" progid="Scripting.Dictionary"></object>
Scripting.Dictionary本身的速度很快,不會對比較StaticObjects集合速度造成太大影響.
Dictionary的速度:
var d=new ActiveXObject("Scripting.Dictionary");
for(var i=0;i<15000;i++){
d.Item(i)="sdfdsffdsaf";}
1.5w次插值,172ms
當(dāng)然自定義對象var d=new Object(); d[i]=..更快,1.5w次只要80-90ms,不過功能弱多了,所以還是用字典.
下面看正式測試
for(var i=0;i<15000;i++){
Application.Lock();
Application.StaticObjects("dict").Item(i)="sdfdsffdsaf";
Application.Unlock();}
時間長達(dá)6953ms,初步判斷StaticObjects集合的訪問速度是不能滿足Cache的要求了,這個速度和ADO OLEDB讀sql server 2000的時間相差無幾。
不過還不打算馬上放棄,因為StaticObjects的優(yōu)勢在于可以存放Object,而Dictionary也可以存放其它對象,這樣可以做為緩存對象,而不僅僅是數(shù)據(jù)。
我在Application.StaticObjects("dict")里面再放入一個Object:
Application.StaticObjects("dict").Item("o")=new Object();
for(var i=0;i<15000;i++){
Application.Lock();
Application.StaticObjects("dict").Item("o")[i]="sdfdsffdsaf";
Application.Unlock();}
6656ms,快了點點.多一層Object并沒有降低速度,那么速度的慢并非結(jié)構(gòu)復(fù)雜,而是StaticObjects的訪問占用。
把dict的引用預(yù)存
var t=Application.StaticObjects("dict");
for(var i=0;i<15000;i++){
Application.Lock();
t.Item("o")[i]="sdfdsffdsaf";
Application.Unlock();}
3094ms,成功的減少一半多點的時間,js中屢試不爽的預(yù)存策略,要是把t.Item("o")也預(yù)存呢?
var t=Application.StaticObjects("dict").Item("o");
for(var i=0;i<15000;i++){
Application.Lock();
t[i]="sdfdsffdsaf";
Application.Unlock();}
125ms,終于成功了,只有Application.Contents的一半??磥頃r間主要花費在取得'引用',而不是StaticObjects內(nèi)存區(qū)被保護(hù)慢。StaticObjects相對Contents安全措施更好,因為里面要存對象。
靠Dictionary強大的功能,適當(dāng)?shù)姆庋b一下,用put(),get(),contains()等等流行方法訪問,就是一個強大的Cache了。
////備注
我封裝了一個.sct組件;asp javascript寫的,有空發(fā)上來,今天到此。
測試了取得Contens和StaticObjects引用的速度,在20次時都是0ms,100次大約5倍速度,500-1500次是10倍速度差距。不過取得后存取不受影響。
不過Application.Contents不能存放對象,可以存vbs數(shù)組,但是在javascript下甚至數(shù)組都不能放。
使用Application.Contents時,只能用丑陋的如:
for(var i=0;i<15000;i++){
Application.Lock();
// Application.Contents(i)="sdfdsffdsaf";
Application(i)="sdfdsffdsaf";
Application.Unlock();}
在這里往Application.Contents存放了1.5w個String,共花費時間234ms.
改用Application.StaticObjects后:
定義一個Dictionary作為StaticObject,用于存放數(shù)據(jù),因為StaticObject是不允許直接訪問的。
<object id="dict" runat="server" scope="Application" progid="Scripting.Dictionary"></object>
Scripting.Dictionary本身的速度很快,不會對比較StaticObjects集合速度造成太大影響.
Dictionary的速度:
var d=new ActiveXObject("Scripting.Dictionary");
for(var i=0;i<15000;i++){
d.Item(i)="sdfdsffdsaf";}
1.5w次插值,172ms
當(dāng)然自定義對象var d=new Object(); d[i]=..更快,1.5w次只要80-90ms,不過功能弱多了,所以還是用字典.
下面看正式測試
for(var i=0;i<15000;i++){
Application.Lock();
Application.StaticObjects("dict").Item(i)="sdfdsffdsaf";
Application.Unlock();}
時間長達(dá)6953ms,初步判斷StaticObjects集合的訪問速度是不能滿足Cache的要求了,這個速度和ADO OLEDB讀sql server 2000的時間相差無幾。
不過還不打算馬上放棄,因為StaticObjects的優(yōu)勢在于可以存放Object,而Dictionary也可以存放其它對象,這樣可以做為緩存對象,而不僅僅是數(shù)據(jù)。
我在Application.StaticObjects("dict")里面再放入一個Object:
Application.StaticObjects("dict").Item("o")=new Object();
for(var i=0;i<15000;i++){
Application.Lock();
Application.StaticObjects("dict").Item("o")[i]="sdfdsffdsaf";
Application.Unlock();}
6656ms,快了點點.多一層Object并沒有降低速度,那么速度的慢并非結(jié)構(gòu)復(fù)雜,而是StaticObjects的訪問占用。
把dict的引用預(yù)存
var t=Application.StaticObjects("dict");
for(var i=0;i<15000;i++){
Application.Lock();
t.Item("o")[i]="sdfdsffdsaf";
Application.Unlock();}
3094ms,成功的減少一半多點的時間,js中屢試不爽的預(yù)存策略,要是把t.Item("o")也預(yù)存呢?
var t=Application.StaticObjects("dict").Item("o");
for(var i=0;i<15000;i++){
Application.Lock();
t[i]="sdfdsffdsaf";
Application.Unlock();}
125ms,終于成功了,只有Application.Contents的一半??磥頃r間主要花費在取得'引用',而不是StaticObjects內(nèi)存區(qū)被保護(hù)慢。StaticObjects相對Contents安全措施更好,因為里面要存對象。
靠Dictionary強大的功能,適當(dāng)?shù)姆庋b一下,用put(),get(),contains()等等流行方法訪問,就是一個強大的Cache了。
////備注
我封裝了一個.sct組件;asp javascript寫的,有空發(fā)上來,今天到此。
測試了取得Contens和StaticObjects引用的速度,在20次時都是0ms,100次大約5倍速度,500-1500次是10倍速度差距。不過取得后存取不受影響。
您可能感興趣的文章:
- HTML5 WebStorage(HTML5本地存儲技術(shù))
- 常見的瀏覽器存儲方式(cookie、localStorage、sessionStorage)
- vue中使用sessionStorage記住密碼功能
- 使用sessionStorage解決vuex在頁面刷新后數(shù)據(jù)被清除的問題
- 使用JS獲取SessionStorage的值
- 詳解Vue中l(wèi)ocalstorage和sessionstorage的使用
- jQuery訪問瀏覽器本地存儲cookie、localStorage和sessionStorage的基本用法
- JS 中LocalStorage和SessionStorage的使用
- JS中LocalStorage與SessionStorage五種循序漸進(jìn)的使用方法
- ASP.NET中Application、Cookie、Session、Cache和ViewState
- ASP.NET中Application和Cache的區(qū)別分析
- 異步 HttpContext.Current實現(xiàn)取值的方法(解決異步Application,Session,Cache...等失效的問題)
- indexedDB bootstrap angularjs之 MVC DOMO (應(yīng)用示例)
- 5個HTML5的常用本地存儲方式詳解與介紹
相關(guān)文章
IIS7.5調(diào)用asp頁面出現(xiàn)800a0e7a的解決辦法
本文給大家分享的是在windows2008R2 64位系統(tǒng)中出現(xiàn)了ADODB.Connection 錯誤 '800a0e7a'的解決辦法,方法很簡單,可是處理過程卻很曲折,這里推薦給大家,有需要的小伙伴可以參考下。2015-05-05asp取動態(tài)表單中數(shù)據(jù)并寫入xml文件,用xsl顯示
asp取動態(tài)表單中數(shù)據(jù)并寫入xml文件,用xsl顯示...2006-09-09