2010-08-02 5 views
3

J'ai une application web utilisant des clients légers (terminaux bosanova) comme frontal pour les utilisateurs. J'ai remarqué des différences de performances en JavaScript entre le client léger et un PC. Les terminaux exécutent Windows XP embarqué avec IE6, et les pages auxquelles je fais référence utilisent le framework prototype JS pour faire une validation plutôt simple sur les éléments de formulaire. Par exemple, voici ce que j'utilise pour m'assurer que les champs obligatoires sont remplis.
Il y en a deux autres comme ceci pour .numeric et .alaphanumeric qui testent de façon acordingly et poussent des erreurs pour arrêter le formulaire de forme soumis.performance javascript entre le client léger et le pc

$$('.requiredfield').each(function (elem){ 
    if (($(elem).value.length == 0) || ($(elem).value == null)) { 
     $(elem).addClassName("nonvalid"); 
     $(elem).siblings().first().addClassName("error"); 
     requiredErrors.push($(elem)); 
    } 

}); 

Le problème que je vois est un PC dans Firefox ou IE un formulaire avec les champs de la 5-20 la page prend peut-être une demi-seconde pour traiter plus que de la validation. Sur le terminal cependant, il faut de 15 à 25 secondes de plus pour exécuter la validation que la même page sans le faire. Comme je crois que j'ai mentionné, j'ai testé cela dans IE6 sur un PC et ne vois pas la perte de performance. Un appel à Bosanova m'a conduit à améliorer la mémoire dans le terminal que j'ai fait juste avant cet affichage et les résultats n'ont pas changé.

Je peux changer le script afin que je boucle une fois les champs de formulaire et manipulez .numeric .alphanumeric .required comme je vais et cela aidera j'en suis sûr. Comme c'est le cas actuellement, il existe une telle différence de performance entre le PC et le Terminal (client léger). Je suis curieux de savoir pourquoi.

Si quelqu'un a une expérience de dépannage ou sait pourquoi prototype/javascript subirait une telle perte de performance sur un terminal j'apprécierais grandement quelques conseils.

Mise à jour: >>>>>>>>>>>>>>>>>

J'ai toujours mis à l'essai et à la recherche sur cette question et ai pensé partager cela. Nous avons reçu hier un Terminal plus récent que j'ai chargé et testé. Le nouveau terminal sous IE6 fonctionnait parfaitement comme tout autre navigateur. bien sûr, il était un peu plus lent qu'un PC parce que 1. son exécution IE6 et 2. son client léger, mais la différence de vitesse était dans les centaines de seconde contre une différence de 10-50 secondes exécutant les mêmes scripts. Les spécifications physiques des 2 différents clients légers ne sont pas si différentes que 1,2 ghz (ancienne) vs 1,6 ghz (nouvelle) mémoire était la même et le HD/DOM était de 512 Mo (ancien) vs 1gig (nouveau). Encore n'ont pas été en mesure de préciser ce qui se passe dans l'ancien terminal, mais semble être lié à ce modèle spécifique/révision du terminal.

Mise à jour: >>>>>>>>>>>>>>>>>

Répondre

0

Je ne sais pas trop sur Prototype, mais vous devez mettre en cache cet élément dans une variable locale au lieu d'envelopper la fonction $ autour d'elle. Je ne pense pas que cela va résoudre tous les problèmes de performances, mais peut-être que cela va réduire quelques secondes. Je suggère d'aller de l'avant avec ce changement que vous avez mentionné afin qu'il vérifie toutes les erreurs/classes dans une boucle au lieu de faire défiler tous les éléments pour chaque type de classe.

Peut-être quelque chose comme (encore une fois, je ne sais pas si bien prototype somethings pourrait être désactivé):

var errors = {}; 

var rules = { 
    ".required": function (elem) { return elem.value.length == 0; }, 
    ".alphanumeric": function (elem) { return /[a-zA-Z0-9]+/.test(elem.value); } 
}; 

$$("input", "#your_form_id").each(function (elem) { 
    var el = $(elem) 
    var classes = (function() { 
     var cls = elem.className.split(' '), classMap = {}; 
     for (var k in cls) classMap[cls[k]] = true; 
     return classMap; 
    })(); // get the classes for this element 

    for (var rule in rules) { 
     error[rule] = []; 
     if (rule in classes && !rules[rule](elem)) { 
      el.addClassName("nonvalid"); 
      el.siblings().first().addClassName("error"); 
      errors[rule].push(el); 
     } 
    } 

}); 

Vos erreurs seront errors .. pour accéder à tous les éléments qui ont échoué la règle nécessaire, vous ferait errors["required"] qui retournerait un tableau.

+0

merci pour les conseils. Je vais admettre volontiers que j'apprends toujours JavaScript. Je suis un programmeur côté serveur par métier qui a barboté dans JavaScript Front-end au cours de la dernière année que les projets ont besoin. Je vais retravailler un peu le matin et voir si je peux rendre tolérable. – Nathan

+0

juste pour mettre à jour. J'ai ajouté certaines de vos suggestions et j'ai accéléré le script. Ce faisant, j'ai été capable de contourner beaucoup de logique jusqu'à ce qu'un utilisateur fasse une erreur. Donc, cela a aidé certains (jusqu'à 8-15 secondes plutôt que 15-20). Il y a toujours une différence drastique entre le PC et le thinclent. – Nathan

+0

@Nathan: Avez-vous envisagé d'utiliser l'une des nombreuses bibliothèques de validation disponibles? Beaucoup d'entre eux vont rendre votre vie beaucoup plus facile, j'en suis sûr. Sauf si vous avez besoin d'un comportement très personnalisé, je suis sûr qu'ils captureront toutes les fonctionnalités dont vous auriez besoin. J'ai en fait ma propre bibliothèque sur laquelle je travaille depuis un moment. –

2

Eh bien, le moteur Javascript de IE6 est lent — rappeler qu'il date d'une époque où Microsoft a insisté pour que tout développement d'application réelle pour le Web devrait bien sûr être fait avec ActiveX. Sur un client léger avec un processeur bon marché, probablement pas trop rapide, il va être vraiment lent.

Vous pouvez accélérer ce code un peu en changeant le sélecteur:

$$('input.requiredfield').each(function (elem){ 
+1

J'ai pensé CPU d'abord aussi mais un de mes clients a un terminal avec un processeur double de la taille de ma boîte de test. En fait, il a fallu plus de temps pour exécuter une page presque identique. BEAUCOUP plus long en fait, presque 40 secondes pour exécuter la validation sur environ 25 champs. – Nathan

+0

Si cela m'arrivait, je programmerais probablement une petite routine de minuterie et commencerais à réduire le temps passé. Notez que des choses comme l'ajout de noms de classes - qui déclenche une nouvelle mise en page - peuvent aussi être très lentes dans IE6. En dehors de cela, cependant, je serais très surpris d'apprendre que le IE6 fonctionnant dans ce client était différent de l'IE6 sur un PC avec XP. – Pointy

+0

yup, mettre une minuterie dans le droit chemin. de nombreuses formes différentes utilisent ce code avec différents nombres de champs requis/numériques/alphanumériques et aucun ne saute comme un porc de ressource. le temps pris pour chacun est proportionnel au nombre de ce type de champ dans le formulaire, comme prévu. Juste beaucoup plus haut sur le terminal que n'importe où ailleurs. J'ai observé la différence dans la façon dont le terminal fait des connexions (il ouvre beaucoup plus de ports) qu'un PC standard par connexion, mais comme le navigateur va je serais surpris aussi .. maintenant je commence à me demander =) – Nathan

Questions connexes