ASP JavaScript application objects Contents and StaticObjects do some of the cache experience _ Application Tips

The Application object has a built-in set of contents for storing simple type designs, and the default application ("Key") is available.

However, application.contents cannot hold objects, you can save the VBS array, but even the array cannot be placed under JavaScript.

When using application.contents, you can only use an ugly example:

for (Var i=0;i<15000;i++) {
Application.Lock ();
Application.Contents (i) = "Sdfdsffdsaf";
Application (i) = "Sdfdsffdsaf";
Application.UnLock ();}

Here, a 1.5w string is stored to the application.contents, which takes a total of 234ms of time.

After you switch to application.staticobjects:
Defines a dictionary as a staticobject for storing data because Staticobject is not allowed to be accessed directly.
<object id= "dict" runat= "Server" scope= "Application" progid= "Scripting.Dictionary" ></object>

The scripting.dictionary itself is very fast and does not have much effect on comparing the staticobjects set speed.

Speed of Dictionary:
var d=new activexobject ("Scripting.Dictionary");
for (Var i=0;i<15000;i++) {
D.item (i) = "Sdfdsffdsaf";}
1.5w time interpolation, 172ms
The custom object, of course, is var d=new object (); D[i]=.. Faster, 1.5w times as long as 80-90ms, but the function is much weaker, so still use a dictionary.

Look at the formal test below
for (Var i=0;i<15000;i++) {
Application.Lock ();
Application.staticobjects ("Dict"). Item (i) = "Sdfdsffdsaf";
Application.UnLock ();}
Time up to 6953MS, the initial determination of StaticObjects set access speed is not enough to meet the requirements of the cache, this speed and ADO OLE DB read SQL Server 2000 time.

But it's not ready to give up now, because the advantage of staticobjects is that it can hold object, and dictionary can hold other objects, which can be cached, 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, it's a little fast. More than one layer of object does not reduce the speed, then the slow speed is not a complex structure, but staticobjects access to occupy.

To store the Dict reference
var t=application.staticobjects ("Dict");

for (Var i=0;i<15000;i++) {
Application.Lock ();
T.item ("O") [i]= "Sdfdsffdsaf";
Application.UnLock ();}

3094ms, the success of the reduction of more than half a point of time, JS proven in the stored strategy, if the T. The Item ("O") is also stored?

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 areas being protected slowly. StaticObjects relative contents security is better because there are objects to be stored inside.

Rely on dictionary powerful function, appropriate encapsulation, with put (), get (), contains () and so popular method access, is a powerful cache.

Note
I encapsulated a. SCT component; ASP JavaScript written, free to send up, today to this.

The speed of obtaining contens and StaticObjects references was tested, at 20 times it was 0ms,100 5 times times, 500-1500 times was 10 times times the speed gap. However, access is not affected after acquisition.