하스켈 String이 만약 실제로 힙에 저장되어 있으면 이걸 읽는게 linked list 라서 느리다는 건 이해하겠는데
파일 io 할때 hGetContents 써서 String 으로 받고 Char를 하나씩 사용하면 이 타입은 그냥 겉으로 보이는 인터페이스 같은거지 실제로 linked list 가 만들어지는게 아니니까 별 상관 없을 것 같은데 아닌가?
파일 io 할때 hGetContents 써서 String 으로 받고 Char를 하나씩 사용하면 이 타입은 그냥 겉으로 보이는 인터페이스 같은거지 실제로 linked list 가 만들어지는게 아니니까 별 상관 없을 것 같은데 아닌가?
기본적으로 리스트 쓰면 cons cell 만들고 지우는게 계속 반복됨. 특정 상황에서는 최적화되서 사라지는것 같기는 한데 정확한 조건은 잘 모름
이거는 lazy 라서 비효율적이라기보다는 그냥 linked list 라서 비효율적인 부분임
음 내 말은 lazy 해서 비효율적이란게 아니라 오히려 lazy 하니까 빠르지 않나 하는 거였음. Eager 하게 파일 전체를 읽어들여서 linked list 를 구성하는게 아니니까. 근데 Char 하나 읽을 때마다 cons cell 을 만들고 지운다면 별 차이가 없나 보네.
ㅇㅇ 어쨋든 만들고 지우는 cons cell 의 총량은 안변함. 근데 mapM_ print [1..100] 같은 코드는 최적화를 잘 해주는지 (아마 리스트 자체를 없애버리는듯) 성능하락 거의 없음
물론 선형 탐색만 하면 시간복잡도를 걱정할 필요는 없늠.