มีการรับประกันอะไรบ้างเกี่ยวกับความซับซ้อนของเวลาทำงาน (Big-O) ของวิธีการ LINQ?

ฉันเพิ่งเริ่มใช้ LINQ ได้ไม่นานและฉันไม่เห็นการกล่าวถึงความซับซ้อนของรันไทม์สำหรับวิธีการใด ๆ ของ LINQ เลย เห็นได้ชัดว่ามีหลายปัจจัยในการเล่นที่นี่ดังนั้นขอ จำกัด การสนทนาเฉพาะIEnumerableผู้ให้บริการ LINQ-to-Objects ธรรมดา นอกจากนี้สมมติว่าสิ่งที่Funcส่งผ่านมาเป็นตัวเลือก / ตัวเปลี่ยน / ฯลฯ เป็นการดำเนินการ O (1) ราคาถูก

ดูเหมือนว่าเห็นได้ชัดว่าทุกการดำเนินงานที่ผ่านเดียว ( Select, Where, Count, Take/Skip, Any/Allฯลฯ ) จะ O (n) เนื่องจากพวกเขาจะต้องเดินตามลำดับเมื่อ; แม้ว่าเรื่องนี้จะเป็นเรื่องขี้เกียจก็ตาม

สิ่งต่าง ๆ มีความซับซ้อนมากขึ้นสำหรับการดำเนินการที่ซับซ้อนมากขึ้น ชุดเหมือนผู้ประกอบการ ( Union, Distinct, Exceptฯลฯ ) การทำงานโดยใช้GetHashCodeค่าเริ่มต้น (AFAIK) ดังนั้นจึงดูเหมือนว่าเหมาะสมที่จะถือว่าพวกเขากำลังใช้กัญชาตารางภายในทำให้การดำเนินงานเหล่า O (n) เช่นกันโดยทั่วไป สิ่งที่เกี่ยวกับเวอร์ชันที่ใช้IEqualityComparer?

OrderByจะต้องมีการเรียงลำดับดังนั้นส่วนใหญ่เราจะดูที่ O (n log n) จะเป็นอย่างไรหากเรียงลำดับแล้ว แล้วถ้าฉันพูดOrderBy().ThenBy()และให้คีย์เดียวกันกับทั้งสองอย่างล่ะ?

ฉันเห็นGroupBy(และJoin) โดยใช้การเรียงลำดับหรือการแฮช มันคืออะไร?

Containsจะเป็น O (n) บน a Listแต่ O (1) บน a HashSet- LINQ ตรวจสอบคอนเทนเนอร์ที่อยู่เบื้องหลังเพื่อดูว่าสามารถเร่งความเร็วได้หรือไม่?

และคำถามที่แท้จริง - จนถึงตอนนี้ฉันเชื่อมั่นว่าการดำเนินงานมีประสิทธิภาพ อย่างไรก็ตามฉันสามารถฝากเงินได้หรือไม่? ตัวอย่างเช่นคอนเทนเนอร์ STL ระบุความซับซ้อนของทุกการดำเนินการอย่างชัดเจน มีการรับประกันที่คล้ายกันเกี่ยวกับประสิทธิภาพของ LINQ ในข้อกำหนดไลบรารี. NET หรือไม่

คำถามเพิ่มเติม (ในการตอบกลับความคิดเห็น):
ไม่ได้คิดเรื่องค่าโสหุ้ย แต่ฉันไม่ได้คาดหวังว่าจะมี Linq-to-Objects ธรรมดา ๆ โพสต์ CodingHorror กำลังพูดถึง Linq-to-SQL ซึ่งฉันสามารถเข้าใจการแยกวิเคราะห์แบบสอบถามและการสร้าง SQL จะเพิ่มต้นทุน - มีค่าใช้จ่ายที่ใกล้เคียงกันสำหรับผู้ให้บริการ Objects ด้วยหรือไม่ ถ้าเป็นเช่นนั้นจะแตกต่างกันหรือไม่หากคุณใช้ไวยากรณ์ที่เปิดเผยหรือใช้งานได้

มีการรับประกันน้อยมาก แต่มีการเพิ่มประสิทธิภาพบางประการ:

• วิธีการขยายที่ใช้จัดทำดัชนีการเข้าถึงเช่นElementAt, Skip, LastหรือLastOrDefaultจะตรวจสอบเพื่อดูหรือไม่ว่าการดำเนินการประเภทพื้นฐานIList<T>เพื่อให้คุณได้รับ O (1) การเข้าถึงแทน O (N)

• CountวิธีการตรวจสอบการICollectionดำเนินงานเพื่อให้การดำเนินการนี้เป็น O (1) แทน O (N)

• Distinct, GroupBy Joinและผมเชื่อว่ายังมีวิธีการติดตั้งรวม ( Union, IntersectและExcept) ใช้คร่ำเครียดดังนั้นพวกเขาควรจะใกล้เคียงกับ O (n) แทน O (N²)

• ContainsตรวจสอบICollectionการนำไปใช้งานดังนั้นจึงอาจเป็น O (1) หากคอลเลกชันพื้นฐานยังเป็น O (1) เช่น a HashSet<T>แต่ขึ้นอยู่กับโครงสร้างข้อมูลจริงและไม่รับประกัน ชุดแฮชจะแทนที่Containsเมธอดนั่นคือเหตุผลว่าทำไมจึงเป็น O (1)

• OrderBy วิธีการใช้ Quicksort ที่เสถียรดังนั้นจึงเป็นกรณีเฉลี่ย O (N log N)

ฉันคิดว่าครอบคลุมมากที่สุดหากไม่ใช่วิธีการขยายในตัวทั้งหมด มีการรับประกันประสิทธิภาพน้อยมาก Linq เองจะพยายามใช้ประโยชน์จากโครงสร้างข้อมูลที่มีประสิทธิภาพ แต่ไม่ใช่การเขียนโค้ดที่อาจไม่มีประสิทธิภาพ

ฉันรู้มานานแล้วว่า.Count()จะส่งคืน.Countหากการแจงนับเป็นIListไฟล์.

แต่ผมก็เสมอ bit เบื่อเกี่ยวกับความซับซ้อนของเวลาทำงานของการดำเนินงานชุด: .Intersect(), ,.Except().Union()

นี่คือการใช้งาน BCL (.NET 4.0 / 4.5) แบบถอดรหัสสำหรับ.Intersect()(ความคิดเห็นของฉัน):

private static IEnumerable<TSource> IntersectIterator<TSource>(IEnumerable<TSource> first, IEnumerable<TSource> second, IEqualityComparer<TSource> comparer)
{
  Set<TSource> set = new Set<TSource>(comparer);
  foreach (TSource source in second)                    // O(M)
    set.Add(source);                                    // O(1)

  foreach (TSource source in first)                     // O(N)
  {
    if (set.Remove(source))                             // O(1)
      yield return source;
  }
}

สรุป:

• ประสิทธิภาพคือ O (M + N)
• การใช้งานไม่ได้ใช้ประโยชน์เมื่อมีการตั้งค่าคอลเล็กชันไว้แล้ว (อาจไม่จำเป็นต้องตรงไปตรงมาเพราะคำที่ใช้IEqualityComparer<T>นั้นต้องตรงกันด้วย)

เพื่อความสมบูรณ์ที่นี่มีการใช้งานสำหรับการและ.Union().Except()

การแจ้งเตือนสปอยเลอร์: พวกเขาก็มี ความซับซ้อนO (N + M)เช่นกัน

private static IEnumerable<TSource> UnionIterator<TSource>(IEnumerable<TSource> first, IEnumerable<TSource> second, IEqualityComparer<TSource> comparer)
{
  Set<TSource> set = new Set<TSource>(comparer);
  foreach (TSource source in first)
  {
    if (set.Add(source))
      yield return source;
  }
  foreach (TSource source in second)
  {
    if (set.Add(source))
      yield return source;
  }
}


private static IEnumerable<TSource> ExceptIterator<TSource>(IEnumerable<TSource> first, IEnumerable<TSource> second, IEqualityComparer<TSource> comparer)
{
  Set<TSource> set = new Set<TSource>(comparer);
  foreach (TSource source in second)
    set.Add(source);
  foreach (TSource source in first)
  {
    if (set.Add(source))
      yield return source;
  }
}

สิ่งที่คุณสามารถทำได้ก็คือเมธอด Enumerable นั้นเขียนไว้อย่างดีสำหรับกรณีทั่วไปและจะไม่ใช้อัลกอริทึมที่ไร้เดียงสา อาจมีเนื้อหาของบุคคลที่สาม (บล็อก ฯลฯ ) ที่อธิบายถึงอัลกอริทึมที่ใช้งานจริง แต่สิ่งเหล่านี้ไม่เป็นทางการหรือรับประกันในแง่ที่อัลกอริทึม STL เป็น

เพื่อเป็นตัวอย่างนี่คือซอร์สโค้ดที่สะท้อนให้เห็น (ได้รับความอนุเคราะห์จาก ILSpy) Enumerable.Countจาก System.Core:

// System.Linq.Enumerable
public static int Count<TSource>(this IEnumerable<TSource> source)
{
    checked
    {
        if (source == null)
        {
            throw Error.ArgumentNull("source");
        }
        ICollection<TSource> collection = source as ICollection<TSource>;
        if (collection != null)
        {
            return collection.Count;
        }
        ICollection collection2 = source as ICollection;
        if (collection2 != null)
        {
            return collection2.Count;
        }
        int num = 0;
        using (IEnumerator<TSource> enumerator = source.GetEnumerator())
        {
            while (enumerator.MoveNext())
            {
                num++;
            }
        }
        return num;
    }
}

อย่างที่คุณเห็นต้องใช้ความพยายามบางอย่างเพื่อหลีกเลี่ยงวิธีแก้ปัญหาที่ไร้เดียงสาในการแจกแจงทุกองค์ประกอบ

ฉันเพิ่งแตกตัวสะท้อนแสงและพวกเขาตรวจสอบประเภทพื้นฐานเมื่อContainsถูกเรียก

public static bool Contains<TSource>(this IEnumerable<TSource> source, TSource value)
{
    ICollection<TSource> is2 = source as ICollection<TSource>;
    if (is2 != null)
    {
        return is2.Contains(value);
    }
    return source.Contains<TSource>(value, null);
}

คำตอบที่ถูกต้องคือ "ขึ้นอยู่กับ" ขึ้นอยู่กับประเภทของ IEnumerable ที่เป็นพื้นฐาน ฉันรู้ว่าสำหรับบางคอลเลกชัน (เช่นคอลเลกชันที่ใช้ ICollection หรือ IList) จะมี codepath พิเศษที่ใช้อย่างไรก็ตามการใช้งานจริงไม่รับประกันว่าจะทำอะไรเป็นพิเศษ ตัวอย่างเช่นฉันรู้ว่า ElementAt () มีกรณีพิเศษสำหรับคอลเล็กชันที่จัดทำดัชนีได้เช่นเดียวกับ Count () แต่โดยทั่วไปแล้วคุณควรถือว่าประสิทธิภาพ O (n) ในกรณีที่แย่ที่สุด

โดยทั่วไปฉันไม่คิดว่าคุณจะพบประเภทของการรับประกันประสิทธิภาพที่คุณต้องการแม้ว่าคุณจะประสบปัญหาด้านประสิทธิภาพโดยเฉพาะกับตัวดำเนินการ linq คุณสามารถนำมาใช้ใหม่สำหรับคอลเลกชันเฉพาะของคุณได้ตลอดเวลา นอกจากนี้ยังมีบล็อกและโครงการความสามารถในการขยายจำนวนมากที่ขยาย Linq ไปยัง Objects เพื่อเพิ่มการรับประกันประสิทธิภาพประเภทนี้ ตรวจสอบดัชนี LINQ ซึ่งขยายและเพิ่มไปยังชุดตัวดำเนินการเพื่อประโยชน์ด้านประสิทธิภาพที่มากขึ้น