String.Contains () có nhanh hơn String.IndexOf () không?

Tôi có bộ đệm chuỗi khoảng 2000 ký tự và cần kiểm tra bộ đệm xem nó có chứa một chuỗi cụ thể hay không.
Sẽ thực hiện kiểm tra trong ứng dụng web ASP.NET 2.0 cho mọi yêu cầu web.

Có ai biết nếu phương thức String.Contains hoạt động tốt hơn phương thức String.IndexOf không?

    // 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);

Sự thật thú vị

Containscuộc gọi IndexOf:

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

Cuộc gọi nào CompareInfo.IndexOf, cuối cùng sử dụng triển khai CLR.

Nếu bạn muốn xem các chuỗi được so sánh như thế nào trong CLR, điều này sẽ hiển thị cho bạn (tìm CaseInsensitiveCompHelper ).

IndexOf(string)không có tùy chọn và Contains()sử dụng so sánh Ordinal (so sánh từng byte thay vì cố gắng thực hiện so sánh thông minh, ví dụ: e với é).

Vì vậy, IndexOfsẽ nhanh hơn một chút (trên lý thuyết) khi IndexOfđi thẳng vào tìm kiếm chuỗi sử dụng FindNLSString từ kernel32.dll (sức mạnh của phản xạ!).

Đã cập nhật cho .NET 4.0 - IndexOf không còn sử dụng so sánh thông thường và do đó Contains có thể nhanh hơn. Xem bình luận bên dưới.

Có lẽ, nó sẽ không có vấn đề gì cả. Đọc bài đăng này trên Coding Horror;): http://www.codinghorror.com/blog/archives/001218.html

Contains (s2) nhanh hơn IndexOf (s2) nhiều lần (trong máy tính của tôi 10 lần) vì Contains sử dụng StringComparison. Cuối cùng là nhanh hơn tìm kiếm nhạy cảm với văn hóa mà IndexOf thực hiện theo mặc định (nhưng điều đó có thể thay đổi trong .net 4.0 http: //davesbox.com/archive/2008/11/12/break-changes-to-the-string-class.aspx ).

Contains có cùng hiệu suất như IndexOf (s2, StringComparison.Ordinal)> = 0 trong các thử nghiệm của tôi nhưng nó ngắn hơn và làm rõ ý định của bạn.

Tôi đang chạy một trường hợp thực (ngược lại với một điểm chuẩn tổng hợp)

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

đấu với

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

Nó là một phần quan trọng trong hệ thống của tôi và nó được thực thi 131,953 lần (cảm ơn DotTrace).

Tuy nhiên , bất ngờ gây sốc , kết quả lại ngược lại với mong đợi

• IndexOf 533ms.
• Chứa 266ms.

: - /

net framework 4.0 (được cập nhật cho ngày 13-02-2012)

Bằng cách sử dụng Reflector, bạn có thể thấy rằng Contains được triển khai bằng IndexOf. Đây là cách thực hiện.

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

Vì vậy, Contains có thể chậm hơn một chút so với việc gọi IndexOf trực tiếp, nhưng tôi nghi ngờ rằng nó sẽ có bất kỳ ý nghĩa nào đối với hiệu suất thực tế.

Nếu bạn thực sự muốn tối ưu hóa vi mô thì cách tốt nhất của bạn luôn là đo điểm chuẩn.

Khung .net có triển khai đồng hồ bấm giờ tuyệt vời - System.Diagnostics.Stopwatch

Từ một bài đọc nhỏ, có vẻ như bên dưới phương thức String.Contains chỉ đơn giản gọi String.IndexOf. Sự khác biệt là String.Contains trả về một boolean trong khi String.IndexOf trả về một số nguyên với (-1) biểu thị rằng không tìm thấy chuỗi con.

Tôi khuyên bạn nên viết một bài kiểm tra nhỏ với 100.000 lần lặp hoặc lâu hơn và tự mình xem. Nếu tôi đoán, tôi muốn nói rằng IndexOf có thể nhanh hơn một chút nhưng giống như tôi đã nói đó chỉ là phỏng đoán.

Jeff Atwood có một bài viết hay về chuỗi tại blog của mình . Nó thiên về nối nhưng có thể hữu ích.

Cũng giống như bản cập nhật cho điều này, tôi đã thực hiện một số thử nghiệm và cung cấp chuỗi đầu vào của bạn khá lớn thì Regex song song là phương pháp C # nhanh nhất mà tôi đã tìm thấy (miễn là bạn có nhiều lõi mà tôi tưởng tượng)

Lấy tổng số trận đấu chẳng hạn -

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

Hi vọng điêu nay co ich!

Sử dụng thư viện điểm chuẩn, như bước đột phá gần đây của Jon Skeet để đo lường nó.

Emptor caveat

Như tất cả các câu hỏi về hiệu suất (vi mô), điều này phụ thuộc vào phiên bản phần mềm bạn đang sử dụng, chi tiết của dữ liệu được kiểm tra và mã xung quanh cuộc gọi.

Như tất cả các câu hỏi về hiệu suất (vi mô), bước đầu tiên phải là có được một phiên bản đang chạy có thể dễ dàng bảo trì. Sau đó, đo điểm chuẩn, lập hồ sơ và điều chỉnh có thể được áp dụng cho các điểm nghẽn đã đo được thay vì phỏng đoán.

Đối với bất kỳ ai vẫn đang đọc phần này, indexOf () có thể sẽ hoạt động tốt hơn trên hầu hết các hệ thống doanh nghiệp, vì hàm chứa () không tương thích với IE!