Dart vs FxDart › #2 · 가장 많이 발생한 로그 레벨

가장 많이 발생한 로그 레벨

FxDart 승

• countBy
• maxBy

요구사항

애플리케이션 로그 일부가 주어질 때, 각 레벨(INFO / WARN / ERROR)이 몇 건씩 있는지 세어, 가장 많이 발생한 레벨을 그 개수와 함께 출력하세요. 데이터는 아래 코드에 있으며, 두 버전 모두 예상 출력 아래에 표시된 줄을 출력해야 합니다.

Most frequent level: WARN (4 of 9)

나란히 보기

차이가 나는 이유

네이티브 Dart에는 countBy가 없습니다. 가장 가까운 것은 package:collection의 groupListsBy인데, 이는 레벨마다 모든 항목의 리스트를 만들어 놓고서 그 길이만 취하는 방식입니다 — 아니면 직접 작성한 Map.update 루프를 쓰거나요. 그런 다음 가장 많은 쪽을 고르려면 명시적인 비교를 담은 reduce가 필요합니다. FxDart는 두 단계 모두에 이름을 붙입니다: countBy는 곧바로 개수로 이어지고(종결 연산자라 평범한 Map을 반환합니다), fx(counts.entries).maxBy(...)는 체인에 다시 들어가 가장 큰 엔트리를 고릅니다. 직접 만든 두 개가 아니라 이름 붙은 두 개의 아이디어입니다.

시간이 실제로 어디로 가는가

세기는 거의 순수한 해시 맵 작업이라, 이 사례는 결국 원소마다 맵을 몇 번 건드리는가에 대한 측정입니다. N=1,000,000에서 원소당 비용으로 쪼개 보면:

순회와 키 추출기는 공짜입니다 — 둘을 합쳐 1 ns가 되지 않습니다. 맵이 전부입니다. 그리고 누구나 떠올릴 그 한 줄, counts[k] = (counts[k] ?? 0) + 1은 맵을 두 번 탐색합니다. 읽으려고 한 번, 다시 쓰려고 한 번. 그 두 번째 탐색이 실행 시간의 약 30%이고, 이름 붙은 연산자가 여러분이 직접 썼을 루프를 이길 수 있는 이유입니다. 0.8.4부터 countBy는 맵 안에 세워 둔 가변 셀에 세므로, 읽기가 셀을 돌려주고 증가는 그 참조를 통해 일어납니다 — 맵은 항목마다가 아니라 서로 다른 레벨마다 한 번 쓰입니다.

벤치마크가 뒤집히는 이유

아래는 같은 사례를 네 가지 규모로 훑은 것으로, 위 문단이 언급만 하고 차트에는 넣지 않은 세 번째 구현 — 직접 작성한 카운팅 루프, 즉 package:collection에 손을 뻗지 않았다면 썼을 코드 — 까지 함께 담았습니다.

마지막 열을 먼저 보세요. 움직이지 않는 열이 그것이니까요: 직접 작성한 루프에 대해 FxDart는 모든 규모에서 ~1.47× 빠릅니다. 만 건에서 백만 건까지 한결같이요. 그 상수가 바로 위에서 본 맵 탐색 한 번입니다 — 연산자는 손으로 쓰기에는 너무 성가신 요령을 감당할 수 있고, 그 배당은 모든 N에서 똑같이 돌아옵니다.

groupListsBy 열은 그 위에 격차를 더 벌리고, 그 이유는 메모리 열에 드러납니다:

countBy와 직접 루프는 같은 메모리를 씁니다 — 모든 규모에서 0.1 MB 이내로요. 둘 다 카운터 네 개 말고는 아무것도 들고 있지 않기 때문입니다. 반면 groupListsBy는 길이만 재려고 백만 건 전부를 레벨별 List로 실체화하고, N=1,000,000에서 그것은 할당해야 할, 그리고 수집기가 훑어야 할 44 MB의 쓰레기입니다.

그 세금은 들쭉날쭉함도 만듭니다. N=1,000,000에서 25개 표본에 걸쳐 groupListsBy는 38.8–50.1 ms로 11 ms를 오갔고, FxDart는 19.1–20.3 ms, 직접 루프는 27.9–30.4 ms였습니다. 느린 표본들은 나머지 둘은 유발하지 않는 수집입니다. 그러니 그 격차는 절반은 파이프라인, 절반은 쓰레기입니다. 나머지 두 열은 파이프라인뿐이고요.

위 막대는 N=10,000에서 FxDart가 넉넉히 앞서는데도 여전히 무승부로 읽힙니다. 365 µs에 대해 191 µs면 174 µs 차이인데, 실재하지만 하네스의 0.6 ms 문턱 아래이기 때문입니다. 174 µs를 느낄 수 있는 사람은 없으니, 배지는 승리를 주장하기를 거부합니다.

그러니 공정한 요약은 이렇습니다: countBy는 직접 루프의 메모리 프로파일을 주면서 직접 루프의 시간을 ~1.47× 이기고, 거기에 이름 붙은 연산자의 가독성까지 줍니다. 라이브러리 쪽이 모든 축에서 그냥 더 나은 선택인 드문 경우이고, 그 이유는 영리한 컴파일이 아니라 연산자는 딱 한 번만 공들여 쓰면 된다는 데 있습니다.