오늘은 어제 시간초과를 내고 할머니집에 가느라 포기했던 문제를 해결하기로 했다.
시간초과는 간단한 중복처리로는 해결되지 않았지만
예전에 진행했던 queue 방식 조회에서 stack 방식 조회로 변경하니 해결할 수 있었고
9회차 경로의 탐색이 1분 이상 걸렸던 것과 다르게 35ms로 사실상 즉시 처리되었으며
이런저런 시도 끝에 12번의 탐색이 필요한 "99 5" 또한 1초정도밖에 걸리지 않는 것을 볼 수 있었다.
그 도중 gpt에게 조언을 구했지만 gpt는 0과 1로 route 체크한 부분을 지우고 true, false로 변경하길 권유했으며
pop 대신 shift 사용을 권유헀는데
pop과 shift 교체는 너무 헛소리라 무시했고
true, false는 최종적으로 정답을 맞춘 후 테스트했지만 오히려 더 오래 걸리는 것을 확인할 수 있었다.
자신있게 내용을 정리하며 이제 시간초과를 해결했다며 안도의 한숨을 쉬는 것도 잠시
메모리초과에 걸려서 제출이 되지 않았고(위 사진을 보면 헷갈리겠지만 저건 종료 후 테스트한 내용이다)
메모리 초과 때문에 가비지컬렉션이나 힙에 대해 더 알아보고
어떤 상황에서 메모리가 절약되는지 생각해볼 수 있는 시간을 가졌다.
이런저런 처리를 진행하며 메모리초과의 최적화 방식에 대해 확인해도
소규모의 해결은 될 수 있지만 대규모 해결은 되지 않았고
방문경로는 탐색하지 않는 것으로 최종적인 문제가 해결되었다.
원래 조합 등에서는 사용되기 어려운 내용이지만 어떤 경로로든 목적지에 도착만 하면 되는 문제였기 때문에
이미 방문했던 경로를 다시 확인할 필요가 없었으며 그 범위도 0~9999로 만개밖에 되지 않았기 때문에 가능했다.
어쨌든 중간에 route체크는 시도했지만
실수로 4개의 분기 중 첫 번째에만 route체크를 적용해 큰 효율성을 느끼지 못하게 되어서 해결되지 않았는데
그걸 모르고 이런저런 최적화 방법을 찾으며 하나씩 개선한 덕분인지 제출자 2위라는 높은 효율성을 볼 수 있었다.
방문경로 저장은 하지 않을 경우 터져버리기 때문에 제출자 전원이 사용했을 것 같고
bfs를 stack으로 처리하는 이중while문 방식이 아마 효과가 컸던게 아닐까 생각된다.
스스로 만든 방식을 통해 효율성에서 높은 순위를 받을 수 있다는 것을 보며
이런저런 시도를 통해 코드를 작성하는 것에 보람을 느끼고
다른 문제에도 도전할 수 있는 힘이 되는 것 같다.
서울에서 헀던 면접 또한 어떻게 보면 유사하게 구조적 최적화 문제인데
이 문제를 어떻게 해야 더 적은 횟수로 해결할 수 있는지를 물어보며
그 과정을 통해서 다른 곳에도 최적화를 할 수 있는지를 보고 싶었던 것 같다.
전에 취득한 토익스피킹점수가 120점이라 다행히 현대 지원 커트라인에 걸리는데
ICT외에는 개발 직군이 아닌 것 같고
ICT는 전공자 우대 또는 전공자만 지원인 것 같기 때문에 애매하다.
그래도 최근 삼성 지원을 할 때 전공, 자격증, 날짜 등 정보를 다 조사해뒀기 때문에
조금 더 여유있어서 현대, 농협도 지원해보기로 했다.
오늘도 10분 이상 운동했다.