11
votes

Parent (), alternative plus rapide?

Je travaille avec un tableau de bord de divs et chaque div, il a un arbre dont les boutons sont. Chaque fois que je dois savoir quel est l'identifiant de cette div, j'utilise donc parent () beaucoup.

La plupart du temps, je fais $ (this) .parent (). Parent (). Parent (). Parent () Code> Pour trouver l'ID de DIV afin que je puisse définir des variables. L'application est basée sur l'identifiant de chaque div. P>

est-il considéré lentement à utiliser parent () jusqu'à 3 fois mais à peu près à chaque fonction? Strong> p> Y a-t-il une autre alternative? P>

Je cherche quelque chose comme un style de référence qui montre ce qui est plus rapide. P>

Voici un exemple de l'arborescence: P>

<div id="6179827893" class="dashdiv">
   <div class="buttons">
     <li><a href="#" class="btn1">Button 1</a></li>
     <li><a href="#" class="btn2">Button 2</a></li>
     <li><a href="#" class="btn3">Button 3</a></li>
     <li><a href="#" class="btn4">Button 4</a></li>
     <li><a href="#" class="btn5">Button 5</a></li>
     <li><a href="#" class="btn6">Button 6</a></li>
   </div>
   <div class="dashcontent">

    ....

   </div>
</div>


2 commentaires

Peut-être que le: contient le sélecteur est une solution. API.JQUERY.COM/Contains-Selector


Connaissez-vous le nom de la classe CSS du parent peut-être?


4 Réponses :


9
votes

Vous serez peut-être mieux à utiliser .clusest () , comme Ceci: $ (this) .closest ('. Dashdiv')

Ce n'est pas plus rapide du point de vue du moteur, car vous bouclez toujours dans les couches DOM, mais il est plus clair pour un nouveau venu et un code plus court.

Commentaire

Si c'est une vitesse pure, vous pouvez aussi bien sauter jQuery entièrement et utiliser nœud.parentnode à la place. Mais cela se heurte à des problèmes niggistes de cycles de comptage et je pense que c'est un académique.

Si vous écrivez un code hautes performances pour une production majeure, comme un moteur de recherche commercial ou un fournisseur de messagerie Web, les cycles de comptage sont importants car toute petite optimisation devient multipliée de milliers de fois. Avec tout le respect due, je doute que vous écriviez ce type de code.

Si vous écrivez quelque chose qui va être frappé par quelques personnes à la fois, les petites optimisations sont un exercice intellectuel qui n'affectera pas les résultats de manière notable. Vous devriez améliorer l'efficacité de votre code de centaines de millisecondes avant que tout utilisateur ne commence à noter que ce code ne va pas faire cela.

Au lieu de cela, il est beaucoup plus important de penser au prochain développeur qui examinera votre code. Pour ce développeur, il est important d'avoir un code clair et bien écrit qui communique immédiatement ce que cela fait. Les chaînes de floue des yeux tels que parent (). Parent (). Parent () Peut obscurer et confondre d'autres développeurs, pour ne rien dire de nœud.parentnode.parentnode.parentnode

- C'est pourquoi .closest () a été créé en premier lieu. Il est clair, concis, et non trop efficacement moins efficace que les chaînes qu'elle remplace. 999 fois sur mille, c'est comme ça que vous devriez aller.


3 commentaires

le plus proche n'est pas considéré plus rapide. JQuery doit rechercher le plus proche où les parents ne


Oui, c'était ma pensée. Mais je pense qu'il y a un petit sacrifice à faire ici en échange de code plus clair et plus concis. Si c'est une vitesse pure, vous pouvez aussi bien sauter jQuery entièrement et utiliser nœud.parentnode à la place.


Merci. Bien répondu. La réponse de Rob sélectionnée comme ce que je vais utiliser et pour la référence



19
votes

Vous avez quelques options pour atteindre le même effet.

Benchmark: http://jsperf.com/parents-method . Selon cette référence, ma méthode est à peu près 100 fois plus rapide que votre méthode. P>

Method (see below) : Operations per second (higher is better)
parentNode3x       : 4447k
$(parentNode3x)    :  204K
$().closest        :   35k
$().parents        :    9k
$().parent()3x     :   44k

// Likely the fastest way, because no overhead of jQuery is involved.
var id = this.parentNode.parentNode.parentNode.id;

// Alternative methods to select the 3rd parent:
$(this.parentNode.parentNode.parentNode) // Native DOM, wrapped in jQuery

// Slowpokes
$(this).closest('.dashdiv')              // Hmm.
$(this).parents('.dashdiv:first')        // Hmm...


5 commentaires

Votre deuxième option est-elle plus rapide que ce que j'ai? Je suppose que le parentnode signifie parent ()


Merci et pour le repère. À peu près ce que je cherchais


Comme vous pouvez le constater, Native DOM / JavaScript est toujours aussi rapide / plus rapide que JQuery. Sauf si vous rencontrez des problèmes de crossbrowser, il est plus efficace d'écrire du code dans Pure JavaScript, surtout si vous appelez le code plusieurs fois, par exemple dans un événement intervalle, boucle ou fréquemment survenant.


@ROBW Ne dis pas "mieux", disons "plus efficace". "Mieux" est relatif. Si j'étais un deuxième développeur en regardant le code de ce utilisateur et que je l'ai vu jonché avec nœud.parentnode.parentnode.parentnode.id sans bon commentaire expliquer pourquoi, je jure sous mon souffle à lui et Commencez à réécrire immédiatement.


vient de changer un tas de code basé sur cela. Merci rob.



2
votes

Tout d'abord, n'étudiez pas prématurément. Si ce n'est pas causant de problème (et testez soigneusement tous les moyens, sur une gamme de plates-formes), ne vous inquiétez pas à ce sujet.

Il y a une optimisation possible: Utilisez des propriétés DOM Native DOM: P>

$(this).closest('div.dashdiv').prop('id');


4 commentaires

Je suis conscient du plus proche mais c'est probablement le plus lent de tous et que l'application devient plus grande et plus grande qui sera une douleur. Je suppose que STOB W a déclaré, le parentnode sera le droit plus rapide?


@jqueryBeast Oui: C'est ce que JQuery utilise en interne .


Ha! Nice sur le lien. Compte tenu de votre "NE PAS optimiser prématurément" Je ne sais pas si je devrais échanger parent () avec parentnode ou le laisser comme il est


Merci pour votre réponse. Je choisirai la réponse de Rob depuis que c'est à peu près la même chose, mais il a répondu en premier