이 기사는 엠티아이 Advent Calendar 2016 20일째 기사입니다.

본 기사의 목적은?

비망록입니다.
이전에, LINQ의 실장 실수로, 데이터 취득 로직의 부하가 높아져, 처리 속도에 큰 영향을 주어 버렸던 적이 있었습니다.
벌써 1개월 정도 전의 이야기입니다만, 얼마나 되어 있었는지 실제로 측정해 보라-, 라고 생각했기 때문에 해 보았습니다.

무슨 실장 실수?

아래입니다.
numsA와 numsB가 쓰고 있는 수치를, result에 격납한다고 하는 간단한 처리를, 수정전과 수정후의 2패턴 써 있습니다.
수정 전과 수정 후의 차이는, ToList() 메소드의 호출 타이밍입니다.
물론 수정 후 쪽이 빨리 처리합니다.

구현시는 좀 더 복잡했지만, 간결하게 하면 이런 느낌입니다.

수정 전

var numsA = Enumerable.Range(1, 100).ToList();
var numsB = Enumerable.Range(1, 100000);
var result = numsA.FindAll(a => numsB.ToList().Exists(b => b == a));

수정 후

var numsA = Enumerable.Range(1, 100).ToList();
var numsB = Enumerable.Range(1, 100000).ToList();
var result = numsA.FindAll(a => numsB.Exists(b => b == a));

무슨 일이야?

LINQ는 지연 평가됩니다.
LINQ는, IEnumerable<T> 오브젝트 이외의, 어떠한 결과를 요구할 때까지, 실체화하지 않습니다.
위의 예에서 List의 메서드 인 .ToList ()는 해당 요청에 해당합니다.

FindAll 메소드는, 대상의 요소분 루프해 무언가의 처리를 실시하는 메소드입니다.
수정 전에는, numsA의 요소분, 매회 numsB를 실체화하고 있으므로, 느려집니다.

구체적으로 이것 정도

numsB, numsA의 요소 수를 변경하여 처리 시간을 측정하여 보았습니다.
측정 방법: System.Diagnostics.Stopwatch 에서 일반적인 방법으로.

Stopwatch sw = new Stopwatch();
sw.Start();
//処理
sw.Stop();

numsB의 요소 수를 변경했을 때의 처리 속도의 차이

우선, 실제 실체화시키고 있는 numsB의 요소수를 100000, 1000000, 10000000으로 변화시킵니다. 아래와 같이 되었습니다.
numsA의 요소 수는 1000으로 고정되어 있습니다.



요소수가 100배가 되었을 때, 수정 후에는 거의 변하지 않았지만, 수정전에서는 지수함수적으로 약 70배로 늘어나고 있습니다.

추기 : 잘 보면 실수하고있었습니다.
수정 후 거의 변하지 않았지만
↓
수정 후의 분들도 마찬가지로 지수 함수적으로 늘어나고 있습니다만, 그래도 1초에는 보지 않는 정도입니다.

numA의 요소수를 10배로 했을 때의 처리 속도의 차이

numsA를 100에서 1000으로 변경했을 때의 차이는 다음과 같습니다.
numsB는 이전에 최대 10,000,000으로 고정됩니다.



루프 수가 10배가 되었으므로, 수정 전의 처리 시간도 확실히 10배(9.69배)로 늘어나고 있습니다.
수정 후 거의 변하지 않았습니다.

상상하고 있던 것 같은 결과가 되었습니다만, 이렇게 재차 보면 무섭네요.

끝에

알고 있는 분으로부터 하면, 당연한 사례일지도 모르지만, 이렇게 측정해 보면 재미있네요.
앞으로도 해 나가려고합니다.

참고문헌

LINQ 처리 중에 사용하는 메모리를 절약하는 방법?