A coleção interna de objetos de aplicativo possui tipos simples de conteúdo, que podem ser usados por aplicativos padrão ("chave"). Abaixo estão algumas experiências na fabricação de cache por conteúdo e StaticObjects de objetos de aplicativos ASP JavaScript. Vamos aprender mais sobre isso abaixo!
Ao usar o Application.Contents, você só pode usar os feios, como:
for (var i = 0; i <15000; i ++) {
Application.lock ();
// Application.Contents (i) = "SDFDSFFDSAF";
Aplicação (i) = "sdfdsffdsf";
Application.unlock ();}
Aqui, eu armazenei as cordas de 1,5W no Application.contents, que levaram um total de 234ms.
Depois de usar o Application.staticObjects:
Defina um dicionário como um StaticObject para armazenar dados, porque o StaticObject não permite acesso direto.
<objeto id = "dict" runat = "server" scope = "aplicativo" program = "script.dictionary"> </object>
O próprio script.dicionário é muito rápido e não terá muito impacto na comparação da velocidade de coleta do StaticObjects.
Velocidade do dicionário:
var d = new ActiveXObject ("script.dictionary");
for (var i = 0; i <15000; i ++) {
d.Item (i) = "SDFDSFFDSAF";}
1.5W Interpolation, 172ms
Obviamente, o objeto personalizado var d = new Object (); d [i] = .. é mais rápido, 1,5W vezes custa apenas 80-90ms, mas a função é muito mais fraca, então você ainda usa um dicionário.
Veja o teste oficial abaixo
for (var i = 0; i <15000; i ++) {
Application.lock ();
Application.staticObjects ("dict"). Item (i) = "sdfdsffdsf";
Application.unlock ();}
O tempo é até 6953ms. Inicialmente, é julgado que a velocidade de acesso da coleção StaticObjects não pode atender aos requisitos do cache. Essa velocidade é quase a mesma do momento em que o ADO OLEDB lê o SQL Server 2000.
No entanto, não pretendo desistir imediatamente, porque a vantagem do StaticObjects é que ele pode armazenar objetos, e o dicionário também pode armazenar outros objetos, que podem ser usados como objetos de cache, não apenas dados.
Coloquei um objeto no 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] = "sdfdsffdsf";
Application.unlock ();}
6656ms, um pouco mais rápido. Mais uma camada de objeto não diminui a velocidade. A velocidade lenta não é por causa da estrutura complexa, mas por causa da ocupação de acesso de StaticObjects.
A referência do dicto antes da loja
var t = Application.staticObjects ("dict");
for (var i = 0; i <15000; i ++) {
Application.lock ();
t.item ("o") [i] = "sdfdsffdsf";
Application.unlock ();}
3094ms, reduziram com sucesso o tempo em mais da metade. E se a estratégia de pré-salvar no JS também for pré-salvar 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, finalmente sucedidos, apenas metade do aplicativo.Contents. Parece que o tempo é gasto principalmente obtendo 'referências', em vez de a área de memória StaticObjects sendo protegida lentamente. O StaticObjects tem melhores medidas de segurança do que o conteúdo, porque os objetos precisam ser armazenados.
Baseando -se nas poderosas funções do dicionário, encapsulam -o adequadamente e acessá -lo usando métodos populares como put (), get (), contém (), etc., é um cache poderoso.
////Observação
Eu encapsulei um componente .SCT; Escrito por ASP JavaScript, enviou -o se você tiver tempo, então estarei aqui hoje.
A velocidade referenciada por Contens e StaticObjects foi testada. Foi 0ms em 20 vezes, 100 vezes a velocidade foi cerca de 5 vezes e 500-1500 vezes é a diferença de velocidade. No entanto, o acesso após a aquisição não será afetado.
Algumas das experiências em criar cache nos objetos de aplicativos JavaScript ASP e StaticObjects são introduzidos aqui. Depois de ler isso, você se beneficiará muito?