9일 동안 못한 이유는 몸 상태 악화.
Record 내부의 List<String> fields 관리 방식
1.
List<String>
2.
String[]
두 개의 관리 방식이 존재함. List<String>의 경우 add를 호출하면 쉽게 배열 확장이 가능함. 하지만 성능상 큰 이점이 존재하지 않을 것 같아보임. 아래의 방식은 유연성이 너무 떨어짐. 기존 add의 경우 api를 사용하지만 해당 방식의 경우 add가 아닌 util class를 이용하여 수동으로 resize를 해줘야함. 또한 *2 형태로 증가할 경우 뒷부분을 제거하는 과정이 한번 더 필요해짐. 이 과정의 오버헤드가 얼마나 발생할지 예측이 안됨.
측정 필요
1.
FieldParser 제작
2.
Record 제작
3.
Record Util 제작
4.
측정
위의 순서로 진행해야 할 것 같음.
가안으로 측정해본결과 기존 row를 바로 String으로 변경했을 때 0.6~0.8/s의 성능을 보임. 하지만 fieldParser 추가 이후 1.7 ~2.0 성능을 보임. 해당 현상이 발생한 원인은 row 파싱 이후 field 파싱을 시행함으로 n^2의 시간 복잡도를 가짐. fastCSV의 경우 field 단위로 파싱을 시행함. 이에 따른 성능차이가 극명하게 발생.