Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📎 문제 링크
https://www.acmicpc.net/problem/1003
📝 풀이 내용
HashMap을 사용해서 dp를 통해 계산한 값을 저장하고 필요할 때 꺼내는 형식 -> 최대 값인 40까지 전부 계산 후 반복문으로 값 출력
그러나 제 풀이에 아쉬움 2가지가 남는데요
입니다.
1번 내용은 말 그대로 문제에서 주어진 N의 최대값을 통해 그 값을 전부 dp를 통해 0과 1의 호출 회수를 구한 것인데요.
이를 최적화 한다면 입력받은 테스트 케이스 중에서 최대값을 구하고 그 최대값만큼만 피보나치 수열을 호출하는 것입니다.
이건 아주 약간의 성능 최적화가 될 거 같아서 그리 중요한 인사이트는 아닐 것 같긴 합니다.
2번 내용은 배열을 쓰지 않고 HashMap을 사용해서 0과 1의 호출 회수를 계산한 것인데
HashMap 계산 과정에서
dp0.get(n)을 하는 순간 내부적으로는 대략:
n이 int라서 Integer로 오토박싱됨
Integer.valueOf(n) 호출 (0~40은 캐시라 그나마 괜찮지만, “원리상” 박싱이 들어감)
hashCode() 계산
Integer는 값 자체가 해시라 빠르긴 해도 “단계가 추가”됨
해시 테이블에서 bucketIndex = (table.length - 1) & hash 계산
해당 버킷에 있는 엔트리(Node)들을 순회하며 key 비교
충돌이 있으면 체이닝/트리 탐색까지
찾은 엔트리의 value 반환 (Integer)
다시 연산하려면 언박싱해서 int로 바꿈
Integer -> int
이런 과정을 거치기 때문에 배열에서 갖고 오는 것이 더 효율적이라고 합니다...
참고로 HashMap이 더 유리해지는 경우는
인덱스로 바로 못 찍는 “희소/가변/비연속 키”를 다룰 때
(배열을 만들면 메모리 낭비가 크거나, 범위를 예측하기 어렵거나, 키가 숫자가 아닐 때)
이런 경우라고 합니당
💬 리뷰 요구사항