[하코테] Day8. 오버헤드 줄이기 (프로그래머스 "기능개선" 풀이)
하코테 8일차 문제 역시 스택/큐 문제입니다.
해당 문제에서는 큐를 이용한 문제 풀이를 하였으나 반드시 자료구조 큐를 이용할 필요없이 성능 향상을 위한 방식을 고려해볼 수 있어습니다.
문제 설명
프로그래머스 팀에서는 기능 개선 작업을 수행 중입니다. 각 기능은 진도가 100%일 때 서비스에 반영할 수 있습니다.
또, 각 기능의 개발속도는 모두 다르기 때문에 뒤에 있는 기능이 앞에 있는 기능보다 먼저 개발될 수 있고, 이때 뒤에 있는 기능은 앞에 있는 기능이 배포될 때 함께 배포됩니다.
먼저 배포되어야 하는 순서대로 작업의 진도가 적힌 정수 배열 progresses와 각 작업의 개발 속도가 적힌 정수 배열 speeds가 주어질 때 각 배포마다 몇 개의 기능이 배포되는지를 return 하도록 solution 함수를 완성하세요.
제한 사항
작업의 개수(progresses, speeds배열의 길이)는 100개 이하입니다.
작업 진도는 100 미만의 자연수입니다.
작업 속도는 100 이하의 자연수입니다.
배포는 하루에 한 번만 할 수 있으며, 하루의 끝에 이루어진다고 가정합니다. 예를 들어 진도율이 95%인 작업의 개발 속도가 하루에 4%라면 배포는 2일 뒤에 이루어집니다.
입출력 예
progresses speeds return
[93, 30, 55] [1, 30, 5] [2, 1]
[95, 90, 99, 99, 80, 99] [1, 1, 1, 1, 1, 1] [1, 3, 2]
입출력 예 설명
입출력 예 #1
첫 번째 기능은 93% 완료되어 있고 하루에 1%씩 작업이 가능하므로 7일간 작업 후 배포가 가능합니다.
두 번째 기능은 30%가 완료되어 있고 하루에 30%씩 작업이 가능하므로 3일간 작업 후 배포가 가능합니다. 하지만 이전 첫 번째 기능이 아직 완성된 상태가 아니기 때문에 첫 번째 기능이 배포되는 7일째 배포됩니다.
세 번째 기능은 55%가 완료되어 있고 하루에 5%씩 작업이 가능하므로 9일간 작업 후 배포가 가능합니다.
따라서 7일째에 2개의 기능, 9일째에 1개의 기능이 배포됩니다.
입출력 예 #2
모든 기능이 하루에 1%씩 작업이 가능하므로, 작업이 끝나기까지 남은 일수는 각각 5일, 10일, 1일, 1일, 20일, 1일입니다. 어떤 기능이 먼저 완성되었더라도 앞에 있는 모든 기능이 완성되지 않으면 배포가 불가능합니다.
따라서 5일째에 1개의 기능, 10일째에 3개의 기능, 20일째에 2개의 기능이 배포됩니다.
문제 풀이
해당 문제는 작업의 순서에 따라서 배포까지 남은 작업기간이 앞선작업과 일치하는지 계속 비교하는 문제로 FIFO(First In First Out)의 큐 자료구조를 혹은 방법론을 이용하는 문제입니다.
1. 배포까지 남은 작업 기간을 계산하여 큐에 넣기
2. 배포할 작업보다 작업 기간이 작거나 같은 작업은 함께 배포 -> 큐에서 함께 제거
방식으로 접근 합니다.
소스 코드
import java.util.Deque;
import java.util.ArrayDeque;
import java.util.List;
import java.util.ArrayList;
class Solution {
public int[] solution(int[] progresses, int[] speeds) {
/*
문제 풀이 개요
함께 배포될 세트를 작업의 순서대로 처리
순차처리 -> 큐
함께 배포 -> 현재 배포할 작업보다 완료 예정기간이 작거나 같은 것
*/
Deque<Integer> q = new ArrayDeque<>(); //완료까지 남은 작업일을 담는 큐
List<Integer> list = new ArrayList<>(); //정답을 담을 리스트
//작업 담기
for(int i = 0; i < progresses.length; i++) {
//남은 작업 기간 -> 소숫점은 하루가 더 필요하므로 올림처리 한다.
int leftD = (int)Math.ceil((100.0 - progresses[i]) / speeds[i]);
q.offer(leftD);
}
//배포일 계산
while(!q.isEmpty()) {
int cnt = 1; //함께 배포될 작업 수
int d = q.poll(); //현재 작업이 완료되기까지 걸리는 기간
//함께 배포될 작업 카운트
while(!q.isEmpty() && q.peek() <= d) {
q.poll();
cnt++;
}
list.add(cnt);
}
return list.stream()
.mapToInt(Integer::intValue)
.toArray();
}
}
해당 코드는 앞선 문제풀이 방식을 순차적으로 코드로 구현한 코드입니다.
남은 작업을 계산하여 큐에 넣기 -> 배포일이 같은 작업을 큐에서 반복적으로 제거하면서 정답 리스트에 적재
시간복잡도 O(logN)
하지만 위 문제의 경우, 작업(porgresses)를 처음부터 끝까지 그대로 봐도 무방하므로 큐 자료구조의 직접 사용하지 않고 풀이가 가능합니다. 그 밖에도 ArrayList를 이용해서 정답을 삽입, Stream을 통한 정답 타입(int 배열)로 변환하면서 오버헤드 등을 줄이는 방식이 가능합니다.
개선된 풀이
import java.util.Arrays;
class Solution {
public int[] solution(int[] progresses, int[] speeds) {
/** 개선된 풀이 */
int n = progresses.length;
// 임시로 최대 n개까지 담을 버퍼
int[] tmp = new int[n];
int k = 0; // 실제 결과 길이
// 첫 작업의 완료일(정수 올림)
int curr = (100 - progresses[0] + speeds[0] - 1) / speeds[0];
int cnt = 1;
for (int i = 1; i < n; i++) {
int day = (100 - progresses[i] + speeds[i] - 1) / speeds[i];
if (day <= curr) {
// 현재 배포 묶음에 포함
cnt++;
} else {
// 지금까지 묶은 개수 확정
tmp[k++] = cnt;
// 새 기준일로 갱신
curr = day;
cnt = 1;
}
}
// 마지막 묶음 추가
tmp[k++] = cnt;
// 결과 크기에 맞춰 잘라서 반환
return Arrays.copyOf(tmp, k);
}
}
1. 불필요한 큐에 담기 제거
2. 올림을 위한 형변환을 제거(float, Math 등 사용 제거)
3. 스트림 오버헤드 제거(List를 Array로 변환하기 위함)
을 통해서 메모리 사용 감소 및 동작 간소화로 성능을 개선할 수 있습니다.
실제 프로그래머스의 결과만 보았을 때, 시간적으로 약 100배 좋은 성능을 낼 수 있습니다.
단순히 문제가 요구하는 카테고리의 자료구조를 사용하여 문제를 풀 수 있지만, 기본형(int 배열 등)의 사용이나 정수형 올림 나눗셈을 이용한 캐스팅 제거, 스트림을 통한 오버헤드 제거 등을 적극적으로 활용해보는 것이 좋은 성능의 코드를 만들 수 있다는걸 체감하게된 좋은 문제였습니다.
'Programming > Algorithm' 카테고리의 다른 글
| [하코테] Day7. 약간고비 (프로그래머스 "주식가격" 풀이) (0) | 2025.09.21 |
|---|---|
| [하코테] Day6. 2주차 시작 (프로그래머스 "같은 숫자는 싫어") (0) | 2025.09.15 |
| [하코테] Day5. 일주일 풀이 완료 (프로그래머스 "완주하지 못한 선수") (0) | 2025.09.13 |
| [하코테] Day4. 작심삼일 극복 (프로그래머스 "베스트 앨범") (0) | 2025.09.13 |
| [하코테] Day3. 작심삼일 달성 (프로그래머스 "폰켓몬" 풀이) (0) | 2025.09.10 |