2010-06-04 33 views
5

Tôi có một ứng dụng mà tôi đã được giao nhiệm vụ dọn dẹp sau đó. Bản thân ứng dụng là tương đối đơn giản - nó chạy một truy vấn SQL, tiêu thụ một dịch vụ web và đưa các kết quả vào một tệp nhật ký. Công việc của tôi là lưu trữ các tệp vào NAS của chúng tôi sau khi ứng dụng được thực hiện với chúng. Nó khóa các tập tin độc quyền cho đến khi nó được thực hiện với họ để nó thêm một chút phức tạp. Tôi cũng không được phép chạm vào ứng dụng, chỉ các bản ghi. Dù sao đơn đăng ký của tôi khá đơn giản:Reverse Streamreader

  1. Kiểm tra xem tệp có thể được mở (bắt IOException) và đánh dấu nó là có thể truy cập được trong bool [] nếu không có ngoại lệ.
  2. Đi qua hàng loạt tệp được đánh dấu đúng, đọc từng dòng của tệp vào StreamReader bằng phương pháp ReadLine. Bởi vì các ứng dụng thỉnh thoảng trục trặc và không kết thúc, tôi không thể chỉ đơn giản là sử dụng IOException để nói nếu tập tin được hoàn thành - Tôi phải thực sự phân tích văn bản.
  3. Nếu văn bản cho biết hoàn thành được tìm thấy, hãy nén tệp, tải tệp đã lưu trữ vào NAS và xóa tệp gốc.

Mã của tôi hoạt động, rất tốn thời gian (các tệp nhật ký là 500 MB). Suy nghĩ của tôi về cải tiến liên quan đến việc bắt đầu tìm kiếm của tôi từ dưới cùng của tập tin thay vì từ đầu, nhưng StreamReader không hỗ trợ một phương pháp như vậy. Tôi không thể sử dụng phương thức ReadToEnd và sau đó đọc ngược lại vì nó chỉ ném ra một ngoại lệ bộ nhớ. Bất kỳ suy nghĩ về một cách tôi có thể tăng tốc độ phân tích cú pháp của tập tin đăng nhập?

+0

bạn có biết rằng phân tích các tập tin là phần chậm? không zip, sao chép vào NAS, xóa hoặc cố gắng để mở tập tin (và có thể không) tất cả những điều đó âm thanh như họ có thể mất một thời gian – luke

+0

Có thể dupe: http://stackoverflow.com/questions/452902/how-to-read -a-text-file-reversely-with-iterator-in-c –

+1

Câu hỏi hay. Vâng, chắc chắn là việc phân tích cú pháp là phần tốn thời gian thực hiện. Tôi đã tách mã thành các hàm riêng lẻ và đặt các điểm ngắt trên mỗi hàm. Quá trình nén mất khoảng 30 - 45 giây, việc phân tích cú pháp có thể mất tới hai giờ. – monkeyninja

Trả lời

6

Tôi giả sử bạn tìm kiếm một điểm đánh dấu ở cuối tệp để xác định xem nó đã hoàn tất chưa? Nếu vậy tôi cũng giả định điểm đánh dấu có độ dài đã biết, ví dụ: một byte đơn hoặc dãy là 3 byte, v.v.

Nếu các giả định trên là chính xác, bạn có thể mở FileStream, Seek vào cuối tệp trừ đi độ dài điểm đánh dấu dự kiến ​​sẽ đọc các byte và nếu điểm đánh dấu có mặt và hoàn tất, bạn biết bạn có thể xử lý tệp.

Seeking đến cùng -3 byte có thể được thực hiện với mã như sau

// Seek -3 bytes starting from the end of the file 
fileStream.Seek(-3, SeekOrigin.End); 
+0

Tìm kiếm có thể là một hoạt động tốn kém hơn so với việc đọc tuần tự và thực hiện nhiều tìm kiếm có thể khá chậm. – josephj1989

+0

Đó là một cái gì đó tôi đã không cố gắng được nêu ra mặc dù vậy nó có giá trị một shot. Tôi sẽ cố gắng thực hiện tìm kiếm và xem điều đó có tăng tốc hay không. Cảm ơn tất cả. – monkeyninja

+3

@ josephj1989, bạn có nói rằng nó nhanh hơn để đọc một dòng tập tin 500 MB theo dòng hoặc trong bộ nhớ thân thiện với khối cho đến khi kết thúc hơn nó chỉ đơn giản là tìm kiếm trực tiếp đến cùng? Và tại sao nhiều tìm kiếm, giả định của tôi đã nêu là điểm đánh dấu ở cuối tệp nên chỉ có một lần tìm kiếm duy nhất. –

Các vấn đề liên quan