LINQ는 느리기 때문에 피해야합니까?

LINQ는 느리기 때문에 피해야합니까?

---

나는 .net linq가 너무 느리기 때문에 우리는 그것을 사용해서는 안되며 다른 사람이 같은 결론을 내 렸는지 궁금해하고 있다고 들었습니다. 예는 다음과 같습니다.

비 LINQ와 비교하여 1000000000을 수행하는 데 1443ms가 걸렸습니다.
LINQ와 비교하여 1000000000을 수행하는 데 4944ms가 걸렸습니다.
(243 % 느림)

비 LINQ 코드 :

for (int i = 0; i < 10000; i++)
{
    foreach (MyLinqTestClass1 item in lst1) //100000 items in the list
    {
        if (item.Name == "9999")
        {
            isInGroup = true;
            break;
        }
    }
}

비 LINQ와 비교하여 1000000000을 수행하는 데 1443ms가 걸렸습니다.

LINQ 코드 :

for (int i = 0; i < 10000; i++)  
    isInGroup = lst1.Cast<MyLinqTestClass1>().Any(item => item.Name == "9999");  

LINQ와 비교하여 1000000000을 수행하는 데 4944ms가 걸렸습니다.

LINQ 코드를 최적화하는 것이 가능하다고 생각하지만 LINQ 코드를 사용하면 안된다는 점을 감안하면 정말 느린 LINQ 코드를 쉽게 얻을 수 있다고 생각했습니다. LINQ가 느리면 PLINQ가 느리고 NHibernate LINQ가 느리기 때문에 LINQ 문에 어떤 종류도 사용해서는 안됩니다.

다른 사람이 LINQ가 너무 느려서 한 번도 사용하지 않았 으면했던 것을 발견 했습니까? 아니면 이와 같은 벤치 마크를 기반으로 너무 일반적인 결론을 내리고 있습니까?

---

Linq는 느리기 때문에 피해야합니까?

아니오 . 충분히 빠르지 않으면 피해야합니다 . 느린 및 속도가 충분히 빠르지 않을 수 있습니다 모든 같은 일에!

Slow 는 고객, 경영진 및 이해 관계자와 관련이 없습니다. 충분히 빠르지 않은 것은 매우 관련이 있습니다. 어떤 것이 얼마나 빠른지 측정하지 마십시오 . 비즈니스 결정을 내리는 데 사용할 수있는 정보가 없습니다. 고객에게 얼마나 가까운 지 측정 하십시오. 받아 들일 수 있다면 더 빨리 만들기 위해 돈을 쓰지 마십시오. 이미 충분합니다.

성능 최적화는 비용 이 많이 듭니다 . 다른 사람이 읽고 관리 할 수 ​​있도록 코드를 작성하는 것은 비용 이 많이 듭니다 . 이러한 목표는 서로 반대되는 경우가 많으므로 이해 관계자의 돈을 책임감있게 사용하려면 충분히 빠르지 않은 작업에 대해 성능 최적화를 수행하는 데 귀중한 시간과 노력 만 쏟고 있는지 확인해야합니다 .

LINQ 코드가 다른 코드 작성 방법보다 느린 인위적이고 비현실적인 벤치 마크 상황을 발견했습니다. 귀하의 고객은 비현실적인 벤치 마크의 속도에 대해 조금이라도 신경 쓰지 않는다고 확신합니다. 그들은 당신이 그들에게 보내는 프로그램이 그들에게 너무 느린 경우에만 관심이 있습니다. 그리고 나는 당신에게 확신합니다. 당신의 경영진은 그것에 대해 조금 신경 쓰지 않습니다. 그들은 눈에 띄지 않을 정도로 빠른 속도의 물건을 만들고 프로세스에서 코드를 읽고 이해하고 유지하는 데 더 많은 비용이 들도록 만드는 데 불필요하게 얼마나 많은 돈을 지출하는지에 관심 이 있습니다.

---

왜 사용하고 Cast<T>()있습니까? 기본적으로 벤치 마크를 판단하기에 충분한 코드를 제공하지 않았습니다.

예, LINQ를 사용하여 느린 코드를 작성할 수 있습니다. 뭔지 맞춰봐? 느린 비 LINQ 코드도 작성할 수 있습니다.

LINQ 는 데이터를 처리하는 코드의 표현력을 크게 지원하며 시작하기 위해 LINQ를 이해하는 데 시간이 걸리는 한 잘 수행되는 코드를 작성하는 것은 어렵지 않습니다.

사람이 말하면 나를 위해 사용 LINQ (객체 특히 LINQ)에 있지 인식 속도의 이유 나는 그들의 얼굴에 웃음 것입니다. 특정 병목 현상이 발생하여 "이 상황에서 LINQ를 사용하지 않음으로써이를 더 빠르게 만들 수 있으며, 여기에 증거가 있습니다"라고 말하면 이는 매우 다른 문제입니다.

---

내가 뭔가를 놓친 것일 수도 있지만, 당신의 벤치 마크가 틀렸다고 확신합니다.

다음 방법으로 테스트했습니다.

• Any확장 방법 ( "LINQ")
• 간단한 foreach루프 ( "최적화 된"방법)
• ICollection.Contains방법 사용
• Any최적화 된 데이터 구조를 이용한 확장 방법 ( HashSet<T>)

다음은 테스트 코드입니다.

class Program
{
    static void Main(string[] args)
    {
        var names = Enumerable.Range(1, 10000).Select(i => i.ToString()).ToList();
        var namesHash = new HashSet<string>(names);
        string testName = "9999";
        for (int i = 0; i < 10; i++)
        {
            Profiler.ReportRunningTimes(new Dictionary<string, Action>() 
            {
                { "Enumerable.Any", () => ExecuteContains(names, testName, ContainsAny) },
                { "ICollection.Contains", () => ExecuteContains(names, testName, ContainsCollection) },
                { "Foreach Loop", () => ExecuteContains(names, testName, ContainsLoop) },
                { "HashSet", () => ExecuteContains(namesHash, testName, ContainsCollection) }
            },
            (s, ts) => Console.WriteLine("{0, 20}: {1}", s, ts), 10000);
            Console.WriteLine();
        }
        Console.ReadLine();
    }

    static bool ContainsAny(ICollection<string> names, string name)
    {
        return names.Any(s => s == name);
    }

    static bool ContainsCollection(ICollection<string> names, string name)
    {
        return names.Contains(name);
    }

    static bool ContainsLoop(ICollection<string> names, string name)
    {
        foreach (var currentName in names)
        {
            if (currentName == name)
                return true;
        }
        return false;
    }

    static void ExecuteContains(ICollection<string> names, string name,
        Func<ICollection<string>, string, bool> containsFunc)
    {
        if (containsFunc(names, name))
            Trace.WriteLine("Found element in list.");
    }
}

Profiler수업 의 내부에 대해 걱정하지 마십시오 . 그것은 단지 Action루프에서 실행하고 Stopwatch시간을 맞추기 위해 사용 합니다. 또한 GC.Collect()가능한 한 많은 노이즈를 제거하기 위해 각 테스트 전에 호출 해야합니다.

결과는 다음과 같습니다.

      Enumerable.Any: 00:00:03.4228475
ICollection.Contains: 00:00:01.5884240
        Foreach Loop: 00:00:03.0360391
             HashSet: 00:00:00.0016518

      Enumerable.Any: 00:00:03.4037930
ICollection.Contains: 00:00:01.5918984
        Foreach Loop: 00:00:03.0306881
             HashSet: 00:00:00.0010133

      Enumerable.Any: 00:00:03.4148203
ICollection.Contains: 00:00:01.5855388
        Foreach Loop: 00:00:03.0279685
             HashSet: 00:00:00.0010481

      Enumerable.Any: 00:00:03.4101247
ICollection.Contains: 00:00:01.5842384
        Foreach Loop: 00:00:03.0234608
             HashSet: 00:00:00.0010258

      Enumerable.Any: 00:00:03.4018359
ICollection.Contains: 00:00:01.5902487
        Foreach Loop: 00:00:03.0312421
             HashSet: 00:00:00.0010222

데이터는 매우 일관성이 있으며 다음과 같은 이야기를 들려줍니다.

• 소박은 USING Any확장 방법은 느린 순순히하여보다 9 % 관한 foreach루프.

• ICollection<string>.Contains최적화되지 않은 데이터 구조 ( )와 함께 가장 적절한 방법 ( )을 사용하면 루프를 사용하는 것 보다 List<string>약 50 % 더 빠릅니다foreach .

• 최적화 된 데이터 구조 ( HashSet<string>)를 사용하면 성능 측면에서 다른 방법을 완전히 제거 할 수 있습니다.

어디서 243 %를 받았는지 모르겠어요. 내 생각 엔 그 모든 캐스팅과 관련이있는 것 같다. 당신은을 사용하는 경우 ArrayList뿐만 아니라 당신이 최적화되지 않은 데이터 구조를 사용하는 다음, 당신은 대부분 사용하고 사용되지 않는 데이터 구조를.

다음에 무엇이 올지 예측할 수 있습니다. "예, 더 잘 최적화 할 수 있다는 것을 알고 있지만 이것은 LINQ와 비 LINQ의 성능을 비교하는 예일뿐입니다."

예,하지만 예제를 철저히 처리 할 수 ​​없다면 어떻게 프로덕션 코드에서 이렇게 철저 할 것으로 기대할 수 있습니까?

결론은 다음과 같습니다.

소프트웨어를 설계하고 설계하는 방법은 사용하는 특정 도구와시기보다 기하 급수적으로 더 중요합니다.

LINQ에서 발생할 가능성이있는 성능 병목 현상이 발생하면 문제를 해결하십시오. 자동화 된 성능 테스트에 대한 Eric의 제안은 훌륭합니다. 당신은 당신이 그들을 해결할 수있는 초기 그래서 문제를 식별하는 데 도움이 될 것입니다이 제대로 되지 당신이 80 % 더 생산하게하지만, <10 %의 성능 저하를 초래하는 일이 놀라운 도구를 기피함으로써, 실제로 의해 - 문제를 조사 하고 올라오고 성능을 2 배, 10 배 또는 100 배 이상 높일 수 있는 실제 솔루션 을 사용합니다.

고성능 응용 프로그램을 만드는 것은 올바른 라이브러리를 사용하는 것이 아닙니다. 그것은 관하여 , 프로파일 링 좋은 디자인의 선택을하고, 좋은 코드를 작성.

---

LINQ가 실제 병목 현상입니까 (응용 프로그램의 전체적 또는인지 된 성능에 영향을 미침)?

애플리케이션이 실제 세계에서 1,000,000,000 개 이상의 레코드에 대해이 작업을 수행합니까? 그렇다면, 대안을 고려하고 싶을 수도 있습니다. 그렇지 않다면 "이 가족 용 세단은 180+ MPH로 잘 운전하지 못하기 때문에 구입할 수 없습니다"라고 말하는 것과 같습니다.

"그냥 느리다"는 것은 그다지 좋은 이유가 아닙니다. 그 이유 때문에 모든 것을 asm / C / C ++로 작성해야하고 C #은 "너무 느리다"는 이유로 테이블에서 벗어나야합니다.

---

조기 비관 화는 조기 최적화만큼 나쁘지만 사용 상황을 고려하지 않고 절대 속도를 기반으로 전체 기술을 배제해서는 안됩니다. 예, 정말로 무거운 숫자 처리를 하고 있고 이것이 병목 이라면 LINQ 가 문제 가 될 수 있습니다.

LINQ를 선호 할 때 사용할 수있는 주장은 손으로 작성한 코드로 성능을 능가 할 수 있지만 LINQ 버전은 더 명확하고 유지 관리하기 쉬울 수 있으며 복잡한 수동 병렬화에 비해 PLINQ의 장점이 있다는 것입니다.

---

이런 종류의 비교의 문제는 추상에서 의미가 없다는 것입니다.

Name 속성으로 MyLinqTestClass1 개체를 해싱하여 시작하면 둘 중 하나를 이길 수 있습니다. 이름별로 정렬하고 나중에 이진 검색을 수행 할 수 있다면 그 사이에서. 실제로 MyLinqTestClass1 객체를 저장할 필요가 없으며 이름 만 저장하면됩니다.

메모리 크기에 문제가 있습니까? 아마도 DAWG 구조에 이름을 저장하고 충분한 것을 결합한 다음이 검사에 사용합니까?

이러한 데이터 구조를 설정할 때 추가 오버 헤드가 의미가 있습니까? 말할 수 없습니다.

또 다른 문제는 그 이름 인 LINQ의 개념과 관련된 다른 문제입니다. MS가 "여기에 함께 작동하는 멋진 새 제품이 많이 있습니다"라고 말할 수있는 것은 마케팅 목적에 적합하지만 사람들이 분리해야하는 종류의 분석을 수행 할 때 함께 결합하는 경우에는 좋지 않습니다. . Any기본적으로 .NET2.0 일에 일반적인 열거 형 필터 패턴을 구현 하는 호출을 해야합니다 (작성하는 것이 더 어색하다는 것은 효율성 이점이있는 곳에서만 사용되었음을 의미하지만 .NET1.1에서는 알려지지 않았습니다. 특정 경우가 정말 중요했습니다.), 람다식이 있고 쿼리 트리가 모두 하나의 개념으로 묶여 있습니다. 느린 것은 무엇입니까?

나는 여기서 답이 람다이고의 사용 Any이 아니라고 장담하지만, 나는 많은 금액 (예 : 프로젝트의 성공)을 걸지 않을 것이고, 테스트하고 확신 할 것이다. 한편, 람다식이 IQueryable과 함께 작동하는 방식은 람다를 사용하지 않고 동등한 효율성으로 작성하는 것이 매우 어려운 특히 효율적인 코드를 만들 수 있습니다.

LINQ가 인위적인 벤치 마크를 통과하지 못해 효율성이 우수 할 때 효율성을 얻을 수 없습니까? 나는 그렇게 생각하지 않는다.

의미있는 곳에서 LINQ를 사용하십시오.

병목 상태의 경우 최적화로서 적절하거나 부적절 해 보임에도 불구하고 멀리 또는 LINQ 로 이동하십시오. 실제 최적화를 더 어렵게 만들 것이므로 먼저 코드를 이해하기 어렵게 작성하지 마십시오.

---

아마도 linq가 느릴 수도 있지만 linq를 사용하면 코드를 매우 간단하게 병렬화 할 수 있습니다.

이렇게 :

lst1.Cast<MyLinqTestClass1>().AsParallel().Any(item => item.Name == "9999");

사이클을 어떻게 병렬화할까요?

---

나에게 이것은 당신이 계약을 맺고 있고 고용주가 LINQ를 이해하지 못하거나 시스템의 성능 병목 현상을 이해하지 못하는 것처럼 들립니다. GUI로 응용 프로그램을 작성하는 경우 LINQ 사용으로 인한 성능에 미치는 사소한 영향은 무시할 수 있습니다. 일반적인 GUI / 웹 앱에서 메모리 내 호출은 전체 대기 시간의 1 % 미만을 차지합니다. 귀하 또는 귀하의 고용주는 1 %를 최적화하려고합니다. 정말 유익한가요?

그러나 디스크 또는 데이터베이스 액세스가 거의없는 과학적이거나 수학 중심의 응용 프로그램을 작성하는 경우 LINQ가 적합하지 않다는 데 동의합니다.

BTW, 캐스트가 필요하지 않습니다. 다음은 첫 번째 테스트와 기능적으로 동일합니다.

       for (int i = 0; i < 10000; i++)
            isInGroup = lst1.Any(item => item.Name == "9999");

10,000 개의 MyLinqTestClass1 개체를 포함하는 테스트 목록을 사용하여 이것을 실행했을 때 원본은 2.79 초에 실행되었고 3.43 초에 수정되었습니다. CPU 시간의 1 % 미만을 차지할 가능성이있는 작업에서 30 %를 절약하는 것은 시간을 잘 활용하는 것이 아닙니다.

---

LINQ가 느려서 nHibernate가 느리다는 것을 언급했기 때문에 흥미로운 관찰이 있습니다. LINQ to SQL (또는 nHibernate에 해당)을 수행하는 경우 LINQ 코드는 루프 코드가 먼저 모든 행을 가져 와서 반복해야하는 SQL 서버의 EXISTS 쿼리로 변환됩니다. 이제 루프 코드가 모든 10K 실행에 대해 모든 데이터를 한 번 (단일 DB 조회) 읽지 만 LINQ 코드는 실제로 10K SQL 쿼리를 수행하도록 이러한 테스트를 쉽게 작성할 수 있습니다. 그것은 아마도 실제로 존재하지 않는 루프 버전에 대해 큰 속도 이점을 보여줄 것입니다. 실제로 단일 EXISTS 쿼리는 쿼리되는 열에 인덱스가없는 경우에도 매번 테이블 스캔 및 루프를 능가합니다 (이 쿼리가 매우 자주 수행되는 경우).

나는 그것이 당신의 테스트의 경우라고 말하는 것이 아닙니다. 우리는 볼 수있는 충분한 코드가 없습니다.하지만 그럴 수도 있습니다. LINQ to Objects와 실제로 성능 차이가있을 수 있지만 LINQ to SQL로 전혀 변환되지 않을 수도 있습니다. 무엇을 측정하고 있으며 이것이 실제 요구 사항에 얼마나 적용되는지 알아야합니다.

---

".net linq가 너무 느리기 때문에 [무엇을 위해?] 우리는 그것을 사용해서는 안된다고 [누가?] 들었습니다."

내 경험상, 누군가 가 한때 당신에게 말한 것만으로 어떤 기술, 도서관 또는 언어와 같은 결정을 내리는 것은 나쁜 생각입니다.

우선 정보가 신뢰할 수있는 출처에서 나온 것입니까? 그렇지 않다면 디자인 결정을 내리기 위해이 (아마도 알려지지 않은) 사람을 신뢰하는 큰 실수를 할 수 있습니다. 둘째,이 정보가 오늘날에도 여전히 관련이 있습니까? 그러나 간단하고 현실적이지 않은 벤치 마크를 기반으로하여 LINQ가 동일한 작업을 수동으로 수행하는 것보다 느리다는 결론을 내 렸습니다. 스스로에게 물어볼 자연스러운 질문은 다음과 같습니다.이 코드 성능이 중요합니까? 이 코드의 성능은 내 LINQ 쿼리의 실행 속도 이외의 다른 요인 (데이터베이스 쿼리, I / O 대기 등)에 의해 제한됩니까?

내가 일하는 방법은 다음과 같습니다.

1. 해결해야 할 문제를 식별하고 이미 알고있는 요구 사항과 제한 사항을 고려하여 가장 간단한 기능 전체 솔루션을 작성합니다.
2. 구현이 실제로 요구 사항을 충족하는지 확인합니다 (충분한 속도입니까? 리소스 소비가 허용 가능한 수준으로 유지됩니까?).
3. 그렇다면 완료된 것입니다. 그렇지 않은 경우 # 2의 테스트를 통과 할 때까지 솔루션을 최적화하고 개선하는 방법을 찾으십시오. 너무 느리기 때문에 포기하는 것을 고려해야 할 수도 있습니다 . 아마도. 그러나 병목 현상이 예상했던 곳이 아닐 가능성이 있습니다.

나에게이 간단한 방법은 하나의 목적으로 사용됩니다. 이미 완벽하게 적절한 코드를 개선하는 데 소요되는 시간 을 최소화 하여 생산성을 극대화하는 것 입니다.

예, 원래 솔루션이 더 이상 문제를 해결하지 못하는 날이 올 수 있습니다. 아니면 그렇지 않을 수도 있습니다. 만약 그렇다면, 그때 거기에서 처리하십시오. 가상 (미래) 문제를 해결하는 데 시간을 낭비하지 않는 것이 좋습니다.

---

네 말이 맞아. LINQ에서 느린 코드를 작성하는 것은 쉽습니다. 다른 것도 옳습니다. LINQ없이 C #으로 느린 코드를 작성하는 것은 쉽습니다.

나는 C에서 당신과 같은 루프를 썼고 그것은 몇 밀리 초 더 빠르게 실행되었습니다. 여기서 얻은 결론은 C # 자체가 느리다는 것입니다.

LINQ-> 루프 확장과 마찬가지로 C에서는 동일한 작업을 수행하는 데 5 배 이상의 코드 줄이 필요하므로 쓰기 속도가 느려지고 읽기 어렵고 버그가 발생할 가능성이 높으며 찾기가 더 어려워집니다. 하지만 10 억 번 반복 할 때마다 몇 밀리 초를 절약하는 것이 중요하다면 그게 종종 필요한 일입니다.

---

시연했듯이 LINQ 코드보다 성능이 우수한 비 LINQ 코드를 작성할 수 있습니다. 그러나 그 반대도 가능합니다. LINQ가 제공 할 수있는 유지 관리 이점을 고려할 때 LINQ로 인해 발생할 수있는 성능 병목 현상이 발생할 가능성이 거의 없으므로 LINQ를 기본값으로 사용하는 것을 고려할 수 있습니다.

즉, LINQ가 작동하지 않는 몇 가지 시나리오가 있습니다. 예를 들어, 많은 양의 데이터를 가져 오는 경우 개별 삽입을 실행하는 작업이 XML 일괄 처리로 SQL Server에 데이터를 보내는 것보다 느릴 수 있습니다. 이 예제에서 LINQ 삽입이 비 LINQ 삽입보다 빠르다는 것이 아니라 대량 데이터 가져 오기를 위해 개별 SQL 삽입을 실행하는 것이 현명하지 않습니다.

---

오히려 가장 효율적인 코드를 작성하기 위해 너무 열심히 노력하지 않아야한다고 말하고 싶습니다.

---

LINQ가 느리면 PLINQ가 느리고 NHibernate LINQ가 느리기 때문에 LINQ 문에 어떤 종류도 사용해서는 안됩니다.

그것은 다른 맥락이지만 엄청나게 다릅니다. 데이터 액세스 작업에 대해 이야기 할 때 전체 10 억 작업에 대한 1.4 초 대 5 초는 관련이 없습니다.

---

테스트 케이스가 약간 왜곡되었습니다. ANY 오퍼레이터는 결과를 열거하기 시작하고 발견하고 종료하면 첫 번째 인스턴스에서 true를 반환합니다. 결과를보기 위해 간단한 문자열 목록으로 이것을 시도하십시오. LINQ를 피하는 것에 대한 질문에 답하려면 실제로 LINQ 사용으로 전환해야합니다. 컴파일 시간 검사 외에도 복잡한 쿼리를 수행 할 때 코드를 더 쉽게 읽을 수 있습니다. 또한 예제에서 Cast 연산자를 사용할 필요가 없습니다.

string compareMe = "Success";
string notEqual = "Not Success";

List<string> headOfList = new List<string>();
List<string> midOfList = new List<string>();
List<string> endOfList = new List<string>();

//Create a list of 999,999 items
List<string> masterList = new List<string>();
masterList.AddRange(Enumerable.Repeat(notEqual, 999999));

//put the true case at the head of the list
headOfList.Add(compareMe);
headOfList.AddRange(masterList);

//insert the true case in the middle of the list
midOfList.AddRange(masterList);
midOfList.Insert(masterList.Count/2, compareMe);

//insert the true case at the tail of the list
endOfList.AddRange(masterList);
endOfList.Add(compareMe);


Stopwatch stopWatch = new Stopwatch();

stopWatch.Start();
headOfList.Any(p=>p == compareMe);
stopWatch.ElapsedMilliseconds.Dump();
stopWatch.Reset();

stopWatch.Start();
midOfList.Any(p=>p == compareMe);
stopWatch.ElapsedMilliseconds.Dump();
stopWatch.Reset();

stopWatch.Start();
endOfList.Any(p=>p == compareMe);
stopWatch.ElapsedMilliseconds.Dump();
stopWatch.Stop();

---

The type casting is of course going to slow your code down. If you care that much, at least used a strongly typed IEnumerable for the comparison. I myself try to use LINQ wherever possible. It makes your code much more concise. It's not not to have to worry about the imperative details of your code. LINQ is a functional concept, which means you'll spell out what you want to happen and not worry about how.

---

There are a thousand times better reasons to avoid Linq.

Following quote from a discussion on Linq names a few of them:

QUOTE1

"For instance this works:

var a = new { x = 1, y = 2 };
a = new { x = 1, y = 3 };

But this does not work:

var a = new { x = 1, y = 2 };
a = new { x = 1, y = 2147483649 };

It returns : Error 1 Cannot implicitly convert type 'AnonymousType#1' to 'AnonymousType#2'

But this works:

var a = new { x = 1, y = 2147483648 };
a = new { x = 1, y = 2147483649 };

When you compile:

var a = new { x = 1, y = 2 };

The type of the x and y components is arbitrarily declared as a 32 bit signed integer, and it is one of the many integer types the platform has, without anything special.

But there is more. For instance this works:

double x = 1.0;
x = 1;

But this does not work:

var a = new { x = 1.0, y = 0 }; 
a = new { x = 1, y = 0 };

The numeric conversion rules are not applicable to this kind of types. As you can see, elegance is in every detail."

QUOTE2

"It appears, then, that 'AnonymousType#1' and 'AnonymousType#2' are not synonymous--they name distinct types. And as { x = 1, y = 2 } and { y = 2, x = 1 } are expressions of those two types, respectively, not only do they denote distinct values, but also values of distinct types.

So, I was right to be paranoid. Now my paranoia extends even further and I have to ask what LinQ makes of the following comparison:

new { x = 1, y = 2 } == new { x = 1, y = 2 }

The result is false because this is a pointer comparison.

But the result of:

(new { x = 1, y = 2 }).Equals(new { x = 1, y = 2 })

Is true.

And the result of:

(new { x = 1, y = 2 }).Equals(new { y = 2, x = 1 })

and

(new { x = 1, y = 2 }).Equals(new { a = 1, b = 2 })

Is false."

QUOTE3

"updates are record oriented :-O

This, I agree, is problematic, and derives from LINQ's sequence-oriented nature.

This is a show stopper for me. If I have to use SQL for my updates anyway why to bother about LinQ?

the optimization in LinQ to objects is unexistent.

There is not any algebraic optimization nor automatic expression rewrite. Many people don't want to use LinQ to Objects because they lose a lot of performance. Queries are executed in the same way as you write them."

참고URL : https://stackoverflow.com/questions/3769989/should-linq-be-avoided-because-its-slow