The built-in collection of application objects has simple types of contents, which can be used by default applications ("key"). Below are some experiences in making Cache by Contents and StaticObjects of ASP javascript Application objects. Let's learn more about it below!
When using Application.Contents, you can only use ugly ones such as:
for(var i=0;i<15000;i++){
Application.Lock();
// Application.Contents(i)="sdfdsffdsaf";
Application(i)="sdfdsffdsaf";
Application.Unlock();}
Here I store 1.5w Strings in Application.Contents, which took a total of 234ms.
After using Application.StaticObjects instead:
Define a Dictionary as a StaticObject to store data, because StaticObject does not allow direct access.
<object id="dict" runat="server" scope="Application" program="Scripting.Dictionary"></object>
Scripting.Dictionary itself is very fast and will not have much impact on comparing StaticObjects collection speed.
Dictionary's speed:
var d=new ActiveXObject("Scripting.Dictionary");
for(var i=0;i<15000;i++){
d.Item(i)="sdfdsffdsaf";}
1.5w interpolation, 172ms
Of course, the custom object var d=new Object(); d[i]=.. is faster, 1.5w times only cost 80-90ms, but the function is much weaker, so you still use a dictionary.
See the official test below
for(var i=0;i<15000;i++){
Application.Lock();
Application.StaticObjects("dict").Item(i)="sdfdsffdsaf";
Application.Unlock();}
The time is as long as 6953ms. It is initially judged that the access speed of the StaticObjects collection cannot meet the requirements of Cache. This speed is almost the same as the time when ADO OLEDB reads SQL server 2000.
However, I don't plan to give up immediately, because the advantage of StaticObjects is that it can store Objects, and Dictionary can also store other objects, which can be used as cache objects, not just data.
I put an Object in Application.StaticObjects("dict"):
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, a little faster. One more layer of Object does not slow down the speed. The slow speed is not because of the complex structure, but because of the access occupation of StaticObjects.
Pre-store dict's reference
var t=Application.StaticObjects("dict");
for(var i=0;i<15000;i++){
Application.Lock();
t.Item("o")[i]="sdfdsffdsaf";
Application.Unlock();}
3094ms, successfully reduced the time by more than half. What if the pre-saving strategy in js is also pre-saving t.Item("o")?
var t=Application.StaticObjects("dict").Item("o");
for(var i=0;i<15000;i++){
Application.Lock();
t[i]="sdfdsffdsaf";
Application.Unlock();}
125ms, finally succeeded, only half of Application.Contents. It seems that time is mostly spent getting 'references', rather than StaticObjects memory area being protected slowly. StaticObjects have better security measures than Contents because objects need to be stored.
Relying on the powerful functions of Dictionary, appropriately encapsulate it, and access it using popular methods such as put(), get(), contains(), etc., it is a powerful cache.
////Remark
I encapsulated a .sct component; written by asp javascript, sent it up if you have time, so I will be here today.
The speed referenced by Contens and StaticObjects was tested. It was 0ms in 20 times, 100 times the speed was about 5 times, and 500-1500 times is the 10 times the speed difference. However, the access after acquisition will not be affected.
Some of the experiences in making Cache in ASP javascript Application objects and StaticObjects are introduced to you here. After reading this, will you benefit a lot?