TStringList 는 로딩시 개행문자를 판별해서 라인을 구분하는 파싱 과정을 거치기에 부적합합니다.
즉, 가변길이 문자열의 개행에 초점이 맞춰져 있는 컴포넌트죠.
말씀하신 장비의 로그화일 같은경우에는, 빠른 처리속도와 검색을 위해서
고정길이로 (Fixed Length Field) 설계하시는게 옳고, 직접 파일처리를 하심이 적당합니다.
만약 직접 파싱하셔서 화면에 뿌릴 경우, 화면에 보이는 만큼만 뿌리면 되므로
어떤 뷰 컴포넌트를 써도 큰 무리 없으리라고 봅니다.
VirtualTree를 쓰셔도 눈에 보이는 화면단위로 넣어주게 되어 있으니까요.

텍스트 검색도 직접 구현하셔야 할텐데,
어쩔 수 없이 가변길이 텍스트를 처리해야만 한다쳐도...
메모리를 충분히 사용하실 수 있을 경우엔, 그냥 문자 배열을 화일 크기만큼 동적 할당하셔서
통째로 200메가를 읽고 검색하시고,
메모리를 충분히 사용하실 수 없는 경우엔, 파일의 블럭단위 (512Byte)씩 읽어서 검색하시는
방법을 쓰실 수 밖에요... 200메가 화일 처리하는데 읽기만 한다면 그다지 시간 걸리지 않습니다.
단순히 블럭단위로 열면서 한 문자씩 읽는데도 오래 걸린다면,
여러개의 대용량 하드를 RAID(스트라이핑 모드)로 연결해 속도를 높이는 물리적인 방법 밖에 없을테구요.

한번 화일을 열어서 복수개의 검색어를 빈번하게 쿼리해야 하는 상황에서는,
검색어 인덱싱을 하는 수 밖에 없을 것 같군요. 이 경우 여러가지 전략이 사용 될 수 있고
가령, 한글을 검색한다 치면 가나다라... 를 배열로 만들어 가로 시작하는 단어들이 발견될때마다
링키드 리스트에 그 파일 포인터를 추가하는... 즉 한글 해싱을 구현해야 하겠죠. (완성된 한글 한자 단위로 인덱싱 하려면 11000개 정도의 배열이 필요할듯... 대신 검색은 이상적일 경우 11000배 빨라진다고 보시면 됩니다.) 영어 로그라면 26개로 족할테구요. (대소문자 가리지 않을 경우)
만약 로그의 메시지에 사용되는 단어가 제한적이라면 다른 편법도 물론 가능하실테고,
특별히 대안이 될 컴포넌트는 존재하지 않을듯 합니다.


크레브 님이 쓰신 글 :
: 예를 들면 200메가 이상의 거대한 텍스트 파일 (장비 로그 데이터 )를
:
: 읽어들이고.. 파싱해서 TreeView 같은 콤포넌트에 표시하고
:
: 텍스트 검색도 하려면
:
: 어떤 콤포넌트, 어떤 방식으로 프로그램을 만들면 좋을까요?
:
: 현재 그냥 TStringList로 핸들링 하는데...
:
: 파일처리가 무지하게 느리고 프로그램 죽은것 같은 현상이 나타납니다.
:
: 게다가 텍스트 검색은 더 힘들고...
:
: VirtualTree가 속도가 빠르다고들 하는데.. 그것을 쓰면 좀 괜찮을까요?