JavaScript: indexOf vs Match lors de la Recherche des Chaînes?

La lisibilité de côté, il y a aucune perceptibles écarts (de performance, peut-être) entre l'utilisation de 

str.indexOf("src")

et 

str.match(/src/)

Personnellement, je préfère match (et regexp) mais les collègues semblent aller dans l'autre sens. Nous nous demandions si c'était ...?

EDIT:

J'aurais dit au début que c'est pour des fonctions qui feront partielle de la plaine-correspondance de chaîne (pour ramasser les identifiants dans les attributs de classe pour JQuery) plutôt que par des recherches à base de regexp avec des caractères génériques, etc.

class='redBorder DisablesGuiClass-2345-2d73-83hf-8293'

La différence entre:

string.indexOf('DisablesGuiClass-');

VS

string.match(/DisablesGuiClass-/)
  • Je pense que str.indexOf("xyz") doit être comparé avec /xyz/.test(str)
  • ici un indice de référence, ce qui se compare indexOf, regex et correspondre jsben.ch/#/r9hBp
  • En fait String.prototype.indexOf est plus comparable à String.prototype.search parce que les deux seront de retour l'index de début de la match. L'expression booléenne 'foo'.indexOf('bar') !== -1 est mieux comparable à /bar/.test('foo') parce que tous deux entraînent une valeur booléenne. Cela dit, pour de simples expressions sans les groupes et les ancrages de la performance devraient être comparables. str.match est perdre en faire trop, car il renvoie à tous les matchs et je ne vous le conseille de l'utiliser pour des comparaisons.Cela dit, si vous n'avez pas de problème de performance choisi celui qui est plus lisible.
InformationsquelleAutor indra | 2011-01-21
  1. 56

    RegExp est en effet plus lent que indexOf (vous pouvez le voir ici), mais normalement cela ne devrait pas être un problème. Avec RegExp, vous aussi, vous devez assurez-vous que la chaîne est correctement échappé, qui est un supplément de chose à penser.

    De ces questions de côté, si les deux outils ne sont exactement ce dont vous avez besoin, pourquoi ne pas choisir le plus simple?

    • Fait sens pour moi, désormais, nous allons être en cours d'exécution avec indexOf moins que de nouvelles RegExp fonctionnalité est requise. Merci beaucoup! PS. Que configurable testpage vous avez accédé à votre réponse est cool - est-il mis à disposition du public d'une chose ou quelque chose de votre propre conception?
    • jsperf, comme jsfiddle, est un outil indispensable pour tester rapidement des idées. C'est un site public, il suffit d'aller à jsperf.com et créer vos propres tests.
    • Cheers, je vais le faire.
    • Selon cette jsperf test simple pas vrai que indexOf est toujours rapide: stackoverflow.com/a/5296314/981933
    • Le test à laquelle vous vous référez peut être précis ou non -- il a certainement eu la RegExp faux, ce qui n'inspire pas confiance. '[\\?|&]' devrait être [?&] correspondre ? ou & -- pas besoin d'un | opérateur, ni de s'échapper de la ?.
    • Juste pour ajouter historiques couleur: Comme la date de ce commentaire, sur ma machine (2017 MBP w/ Chrome 56.0.2924 sur Mac OS X 10.12.3), le critère lié à la réponse dit que le indexOf est 12% plus lent que le regex match. Donc, avec beaucoup de choses, la bonne réponse est sans doute: Ça dépend.
    • Je ne pense pas que c'est un résultat complet depuis l'OP était en train de parler sur la correspondance de chaînes, et dans un scénario du cas d'utilisation. Le test à la recherche de deux cordes différentes dans la même OU conditionnelle, match/regexp méthodes peuvent être incroyablement lent par rapport à indexOf (90%). Si vous vous trouvez dans une situation où vous pouvez faire le modèle de recherche plus laconique dans des situations comme le test (modèle en une seule regexp), le match est presque plus que certainement le meilleur choix que vous êtes également de réduire la quantité de code de gestionnaire ainsi.
    • Le jsperf également recréé les regex dans chaque cas de test, ce qui a ralenti la non-regex cas de manière significative. Vérifier jsperf.com/regexp-vs-indexof/52 et de voir que la regex est ~96% plus lent en plus de cas réels.
    • Certainement semble dépendre, et ont peut-être changé depuis les dernières observations ont été faites... Ce test de référence montre regex (surtout pré-compilé) est plus rapide: jsben.ch/Jw5yT

    InformationsquelleAutor David Tang
  2. 19

    Votre comparaison ne peut pas être tout à fait juste. indexOf est utilisé avec plaine de chaînes de caractères et est donc très rapide; match prend une expression régulière - bien sûr, il peut être plus lent en comparaison, mais si vous voulez faire une regex match, vous n'irez pas loin avec indexOf. D'autre part, des moteurs d'expressions régulières peuvent être optimisés, et ont été l'amélioration de la performance dans les dernières années.

    Dans votre cas, si vous êtes à la recherche d'un verbatim de la chaîne, indexOf devrait être suffisant. Il y a toujours une demande pour les regexes, même si: Si vous avez besoin de faire correspondre ensemble mots et que vous voulez éviter les chaînes de correspondance, puis les expressions régulières vous donner "frontière de mot ancres". Par exemple:

    indexOf('bar')

    trouverez bar trois fois dans bar, fubar, barmy, alors que

    match(/\bbar\b/)

    ne correspondent bar quand il ne fait pas partie d'un plus long terme.

    Comme vous pouvez le voir dans les commentaires, certaines comparaisons ont été faites qui montrent que d'une expression régulière peut être plus rapide que indexOf - si c'est la performance est critique, vous devrez peut-être le profil de votre code.

    • Toutes mes excuses, je n'ai pas fournir assez d'information, les pls voir modifier ci-dessus.
    • J'ai pensé que c'était une bonne question, à venir à partir d'un Perl arrière-plan, où un équivalent regex est plus rapide que indexOf.
    • C'est pas des pommes avec des oranges comparaison comme une simple regex peut être optimisé pour être aussi rapide que indexOf. Je viens de lancer jsperf.com/substring-test, et il affirme que "l'expression régulière insensible à la casse" est la manière la plus rapide et 30% plus rapide que le "indexOf", dont je refuse de croire.
    InformationsquelleAutor Tim Pietzcker
  3. 9

    Si vous êtes à la recherche de sous-chaîne occurrences cas insensiblement puis match semble être plus rapide qu'une combinaison de indexOf et toLowerCase()

    Vérifier ici - http://jsperf.com/regexp-vs-indexof/152

    • Peut confirmer, voici un autre (de travail) de référence: jsben.ch/Jw5yT -- Avis, regex gagne à tous les coups si les pré-compilé ou non, même plus rapide que la casse de l'indice de selon ce.
    InformationsquelleAutor Yogesh Mangaj
  4. 7

    Ici toutes les façons possibles (relativement) à la recherche de chaîne de

    //1. comprend (introduit dans l'ES6) 

    var string = "string to search for substring",
    substring = "sea";
string.includes(substring);

    //2. chaîne de caractères.indexOf

    var string = "string to search for substring",
    substring = "sea";
string.indexOf(substring) !== -1;

    //3. RegExp: test

    var string = "string to search for substring",
    expr = /sea/;  //no quotes here
expr.test(string);

    //4. chaîne de caractères.match

    var string = "string to search for substring",
    expr = "/sea/";
string.match(expr);

    //5. chaîne de caractères.recherche

    var string = "string to search for substring",
    expr = "/sea/";
string.search(expr);

    Ici src: https://koukia.ca/top-6-ways-to-search-for-a-string-in-javascript-and-performance-benchmarks-ce3e9b81ad31

    Repères semblent être tordu spécialement pour es6 comprend , lisez les commentaires.

    En résumé:

    si vous n'avez pas besoin de les matchs.
    => Soit vous avez besoin de regex et donc de l'utiliser test. Sinon es6 comprend ou indexOf. Encore test vs indexOf sont proches.

    Et comprend vs indexOf:

    Ils semblent être les mêmes : https://jsperf.com/array-indexof-vs-includes/4 (si c'était différent, il serait bizarre, ils effectuent principalement le même, sauf pour les différences qu'ils exposent cochez cette)

    Et pour mon propre test de référence. ici, il est http://jsben.ch/fFnA0
    Vous pouvez le tester (c'est le navigateur charge) [test plusieurs fois]
    voici comment il a réalisé (terme multiples indexOf et comprend un battement à l'autre, et ils sont proches). Ils sont donc les mêmes. [ici, en utilisant la même plate-forme de test comme l'article ci-dessus].

    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?
    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?

    Et ici pour le texte long version (8 fois plus)
    http://jsben.ch/wSBA2

    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?

    Testé chrome et firefox, même chose.

    Avis jsben.ch ne gère pas de débordement de la mémoire (ou il y a des limites correctement. Elle ne montre aucun message) donc le résultat peut se tromper si vous ajoutez plus de 8 texte de la duplication (8 fonctionnent bien). Mais la conclusion est pour les très gros texte tous les trois de la même façon. Sinon pour faire court indexOf et comprend sont les mêmes et tester un peu plus lent. ou Peut être le même, car il ne semblait chrome (firefox 60 ans, il est plus lent).

    Avis jsben.ch: pas de panique si vous obtenez incompatible résultat. Essayez différents temps et voir si elle est compatible ou pas. Changer de navigateur, parfois, ils se contentent d'exécuter totalement faux. Bug ou d'une mauvaise manipulation de la mémoire. Ou quelque chose.

    ex:

    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?

    Ici aussi ma référence sur la jsperf (mieux de détails et gérer des graphiques pour plusieurs navigateurs)

    (en haut chrome)

    texte normal
    https://jsperf.com/indexof-vs-includes-vs-test-2019

    résumé: comprend et indexOf ont même perofrmance. test plus lent.

    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?
    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?
    (semblent tous les trois d'effectuer la même dans chrom)

    Long texte (12 fois plus que la normale)
    https://jsperf.com/indexof-vs-includes-vs-test-2019-long-text-str/

    résumé: Tous les trois d'effectuer la même. (chrome et firefox)
    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?

    très courte chaîne
    https://jsperf.com/indexof-vs-includes-vs-test-2019-too-short-string/

    résumé: comprend et indexOf effectuer la même et de tester plus lent.

    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?

    Note: à propos de l'indice de référence ci-dessus. Pour le très courte chaîne version (jsperf) a eu une grosse erreur de chrome. Voir par mes yeux. autour de 60 échantillon a été exécuté pour les deux indexOf et inclut même façon répétée beaucoup de temps). Et de tester un peu moins et donc plus lent.
    ne vous laissez pas berner avec le mauvais graphique. Il est clair que de mal. Même test ok pour firefox, sûrement c'est un bug.

    Ici l'illustration: (la première image est le test sur firefox)
    JavaScript: indexOf vs Match lors de la Recherche des Chaînes?
    waaaa. Soudain indexOf est devenu superman. Mais comme je l'ai dit j'ai fait le test, et regardé le nombre d'échantillons, il était autour de 60. Les deux indexOf et comprend et ils ont fait la même. Un bug sur jspref. Sauf pour celui-ci (peut-être en raison d'un problème lié à la restriction de la mémoire) tout le reste est cohérent, il donnera plus de détails. Et vous voyez combien de simple lieu en temps réel.

    Résumé Final

    indexOf vs comprend => Même performance

    test => peut être plus lente pour les chaînes courtes ou texte. Et même pour les longs textes. Et il un sens pour les frais généraux que le moteur d'expressions régulières ajouter. Dans google chrome, il semblait qu'il n'a pas d'importance du tout.

    • :pouce vers le haut: pour les efforts 🙂
    InformationsquelleAutor Mohamed Allal
  5. 6

    Vous demandez si str.indexOf('target') ou str.match(/target/) doit être préféré. Comme d'autres affiches ont suggéré, les cas d'utilisation et les types de retour de ces méthodes sont différentes. Le premier demande: "où en str puis-je d'abord trouver 'target'?" La deuxième demande "ne str correspondent à l'expression régulière et, dans l'affirmative, quels sont tous les matchs pour tout associé groupes de capture?"

    Le problème est que ni l'un, techniquement, est conçu pour poser la simple question "est ce que la chaîne de caractères contenant la sous-chaîne?" Il y a quelque chose qui est explicitement conçu pour le faire:

    var doesStringContainTarget = /target/.test(str);

    Il y a plusieurs avantages à utiliser regex.test(string):

    1. Elle retourne un booléen, qui est ce que vous vous souciez de
    2. Il est plus performant que str.match(/target/) (et rivaux str.indexOf('target'))
    3. Si pour une raison quelconque, str est undefined ou null, vous aurez false (le résultat souhaité) au lieu de lancer un TypeError
    InformationsquelleAutor elreimundo
  6. 5

    À l'aide de indexOf devrait, en théorie, être plus rapide qu'une regex, quand vous êtes juste à la recherche pour certains de texte brut, mais vous devriez faire un peu de repères comparatifs vous-même si vous êtes préoccupé par la performance.

    Si vous préférez match et il est assez rapide pour vos besoins, alors aller pour elle.

    Pour ce que ça vaut, je suis d'accord avec vos collègues sur ce point: je ne l'utiliserais indexOf lors de la recherche d'une simple chaîne de caractères, et l'utilisation match etc seulement quand j'ai besoin de la fonctionnalité supplémentaire fournie par des expressions régulières.

    InformationsquelleAutor LukeH
  7. 4

    Performance sage indexOf sera à tout le moins être légèrement plus rapide que match. Tout se résume à la mise en œuvre spécifique. Lorsque vous décidez de l'utiliser, posez-vous la question suivante:

    Sera un index entier est-elle suffisante ou dois-je
    besoin de la fonctionnalité d'une RegExp
    le résultat du match?

    InformationsquelleAutor ChaosPandion
  8. 3

    Les valeurs de retour sont différents

    Côté de l'incidence sur les performances, qui sont traitées par d'autres réponses, il est important de noter que les valeurs de retour pour chaque méthode sont différents, de sorte que les méthodes ne peuvent pas simplement être remplacé, sans modifier votre logique.

    Valeur de retour de .indexOf: integer

    L'index au sein de l'appelant String objet de la première occurrence de la valeur spécifiée, en commençant la recherche à fromIndex.
    Retourne -1 si la valeur n'est pas trouvée.

    Valeur de retour de .match: array

    Un Tableau contenant l'ensemble de la correspondance et toutes les parenthèses-capturé appariés résultats.
    Retourne null si il n'y avait pas de matchs.

    Parce que .indexOf retourne 0 si l'appel de la chaîne commence avec la valeur spécifiée, une simple truthy test échouera.

    Par exemple:

    Compte tenu de cette classe...

    class='DisablesGuiClass-2345-2d73-83hf-8293 redBorder'

    ...le retour de valeurs pour chaque serait différent:

    // returns `0`, evaluates to `false`
if (string.indexOf('DisablesGuiClass-')) {
    … //this block is skipped.
}

    vs

    // returns `["DisablesGuiClass-"]`, evaluates to `true`
if (string.match(/DisablesGuiClass-/)) { 
    … //this block is run.
}

    La bonne façon d'exécuter une truthy test avec le retour de .indexOf est à l'épreuve de contre -1:

    if (string.indexOf('DisablesGuiClass-') !== -1) {
// ^returns `0`                        ^evaluates to `true`
    … //this block is run.
}
    InformationsquelleAutor gfullam
  9. 0

    toujours utiliser indexOf pour l'existence de sous-chaînes et match uniquement lorsque vous en avez besoin. c'est à dire si vous avez été la recherche pour le mot src dans une chaîne qui peut également contenir des altsrc puis aString.match(/\bsrc\b/) est en effet plus approprié.

    InformationsquelleAutor Walf
  10. 0

    souviens d'Internet Explorer 8 ne comprennent pas indexOf.
    Mais si personne ne de vos utilisateurs utilise ie8 (google analytics vous dire) que d'omettre cette réponse.
    solution possible pour résoudre ie8:
    Comment fixer le Tableau indexOf() en JavaScript pour les navigateurs Internet Explorer

    InformationsquelleAutor NoWomenNoCry