String.Contains () è più veloce di String.IndexOf ()?

Ho un buffer di stringa di circa 2000 caratteri e devo controllare il buffer se contiene una stringa specifica.
Farà il controllo in una webapp ASP.NET 2.0 per ogni webrequest.

Qualcuno sa se il metodo String.Contains funziona meglio del metodo String.IndexOf ?

    // 2000 characters in s1, search token in s2
    string s1 = "Many characters. The quick brown fox jumps over the lazy dog"; 
    string s2 = "fox";
    bool b;
    b = s1.Contains(s2);
    int i;
    i = s1.IndexOf(s2);

Fatto divertente

Containschiamate IndexOf:

public bool Contains(string value)
{
    return (this.IndexOf(value, StringComparison.Ordinal) >= 0);
}

Che chiama CompareInfo.IndexOf, che in ultima analisi utilizza un'implementazione CLR.

Se vuoi vedere come vengono confrontate le stringhe nel CLR, questo ti mostrerà (cerca CaseInsensitiveCompHelper ).

IndexOf(string)non ha opzioni e Contains()utilizza un confronto ordinale (un confronto byte per byte anziché tentare di eseguire un confronto intelligente, ad esempio, e con é).

Quindi IndexOfsarà leggermente più veloce (in teoria) poiché IndexOfva direttamente a una ricerca di stringhe utilizzando FindNLSString da kernel32.dll (la potenza di reflector!).

Aggiornato per .NET 4.0 : IndexOf non usa più Ordinal Comparison e quindi Contains può essere più veloce. Vedi commento sotto.

Probabilmente non avrà alcuna importanza. Leggi questo post su Coding Horror;): http://www.codinghorror.com/blog/archives/001218.html

Contains (s2) è molte volte (nel mio computer 10 volte) più veloce di IndexOf (s2) perché Contains utilizza StringComparison.Ordinal che è più veloce della ricerca sensibile alle impostazioni cultura che IndexOf esegue per impostazione predefinita (ma potrebbe cambiare in .net 4.0 http: //davesbox.com/archive/2008/11/12/breaking-changes-to-the-string-class.aspx ).

Contains ha esattamente le stesse prestazioni di IndexOf (s2, StringComparison.Ordinal)> = 0 nei miei test, ma è più breve e rende chiaro il tuo intento.

Sto conducendo un caso reale (al contrario di un benchmark sintetico)

 if("=,<=,=>,<>,<,>,!=,==,".IndexOf(tmps)>=0) {

contro

 if("=,<=,=>,<>,<,>,!=,==,".Contains(tmps)) {

È una parte vitale del mio sistema e viene eseguito 131.953 volte (grazie DotTrace).

Per quanto sconvolgente sorpresa , il risultato è l'opposto di quanto previsto

• Indice di 533 ms.
• Contiene 266 ms.

: - /

net framework 4.0 (aggiornato al 13-02-2012)

Usando Reflector, puoi vedere che Contains è implementato usando IndexOf. Ecco l'implementazione.

public bool Contains(string value)
{
   return (this.IndexOf(value, StringComparison.Ordinal) >= 0);
}

Quindi Contains è probabilmente un po 'più lento rispetto alla chiamata diretta di IndexOf, ma dubito che avrà alcun significato per le prestazioni effettive.

Se vuoi davvero ottimizzare al minimo il tuo codice, il tuo approccio migliore è sempre il benchmarking.

Il framework .net ha un'eccellente implementazione del cronometro: System.Diagnostics.Stopwatch

Da una piccola lettura, sembra che sotto il cofano il metodo String.Contains chiama semplicemente String.IndexOf. La differenza è che String.Contains restituisce un valore booleano mentre String.IndexOf restituisce un numero intero con (-1) che rappresenta che la sottostringa non è stata trovata.

Suggerirei di scrivere un piccolo test con circa 100.000 iterazioni e vedere di persona. Se dovessi indovinare, direi che IndexOf potrebbe essere leggermente più veloce ma come ho detto è solo un'ipotesi.

Jeff Atwood ha un buon articolo sulle stringhe nel suo blog . Si tratta più di concatenazione, ma può comunque essere utile.

Proprio come un aggiornamento a questo ho fatto alcuni test e fornendo la tua stringa di input è abbastanza grande, quindi Regex parallelo è il metodo C # più veloce che ho trovato (a condizione che tu abbia più di un core immagino)

Ottenere la quantità totale di corrispondenze, ad esempio:

needles.AsParallel ( ).Sum ( l => Regex.IsMatch ( haystack , Regex.Escape ( l ) ) ? 1 : 0 );

Spero che questo ti aiuti!

Usa una libreria di benchmark, come questa recente incursione di Jon Skeet per misurarla.

Caveat Emptor

Come tutte le domande sulle (micro) prestazioni, ciò dipende dalle versioni del software in uso, dai dettagli dei dati esaminati e dal codice che circonda la chiamata.

Come tutte le domande sulle (micro) prestazioni, il primo passo deve essere quello di ottenere una versione funzionante che sia facilmente gestibile. Quindi benchmarking, profiling e tuning possono essere applicati ai colli di bottiglia misurati invece di supporre.

Per chiunque stia ancora leggendo questo, indexOf () probabilmente funzionerà meglio sulla maggior parte dei sistemi aziendali, poiché contiene () non è compatibile con IE!