Cơ chế mã hóa từng byte hay một vùng năm 2024
Đặc biệt dành cho Show Bắt đầu nàoỞ cấp độ 18, nhiệm vụ đầu tiên của việc đọc tệp theo từng byte bắt đầu: đọc tệp, sau đó tìm byte tối thiểu/tối đa hoặc xuất tệp ở dạng có thứ tự, v.v. Người dân ở đây rất thông minh. Họ biết về các bộ sưu tập và họ có thể sắp xếp và chèn. Bộ sưu tập là một cơ chế mạnh mẽ. Và nhiều người đã không sử dụng chúng trước JavaRush. Tất nhiên, việc nghiên cứu chúng và cố gắng đánh sai chỗ là điều đáng khen ngợi. Vì thế. Chúng ta hãy giải một bài toán không có trong nhiệm vụ (để không bị tiết lộ nội dung khi giải), nhưng có những bài toán rất giống nhau:
Hãy giải quyết nó trực tiếp:
Giải quyết mọi thứ tuyệt vời! Bài kiểm tra (nếu có thì nó đã vượt qua một cách thành công). Nhưng ở đời hiếm có tập hồ sơ nào chỉ chứa dòng chữ “Mẹ giặt khung”. Hãy cung cấp cho chương trình của chúng ta một tệp 46 MB (theo tiêu chuẩn ngày nay, nó có vẻ không nhiều). Nó là gì, chương trình chạy trong 220 giây. Nỗ lực nạp tệp 1Gb vào buổi tối (kích thước của phim MPEG4 không có chất lượng tốt nhất) đã không thành công. Tôi vẫn đang đọc chương trình vào buổi sáng - và tôi phải đi làm rồi. Vấn đề là gì? Có lẽ đang được sử dụng `ArrayList Gặp gỡ câyĐây là rất nhiều:
Đầu ra là: tệp 46MB, 176 giây. Tệp 1Gb - 3 giờ 5 phút. Sự tiến bộ là rõ ràng. Chúng tôi có thể “chờ” kết quả và tệp 46MB được xử lý nhanh hơn đáng kể. Hãy tiếp tục. Chúng ta hãy cố gắng từ bỏ các bộ sưu tập (điều này sẽ vô cùng đau đớn đối với một số người). Chúng ta sẽ sử dụng các mảng đơn giản (nó rất nguyên thủy). Hãy lưu ý một điều quan trọng . Số byte gặp phải có thể được đưa vào một mảng có độ dài 256. Vì vậy, chúng ta sẽ chỉ cần tăng phần tử mảng tương ứng với byte đọc lên một. Mảng - từng byte
Đầu ra là: tệp 46 MB, 158 giây. Tệp 1Gb - 2 giờ 55 phút. Một lần nữa một cải tiến, nhưng nhỏ. Và chúng tôi đã làm mọi thứ bằng những công cụ đơn giản. Không sử dụng kính hiển vi để đóng đinh . Bây giờ là một sự lạc đề trữ tình. Hãy nhớ lại cấu trúc của một máy tính. Bộ nhớ RAM (DRAM) , nơi chương trình thường được thực thi và các biến được lưu trữ, có tốc độ truy cập cao nhưng kích thước nhỏ. Bộ nhớ trên ổ cứng/flash (ổ HDD hoặc ổ Flash), nơi thường lưu trữ các tập tin, ngược lại, có tốc độ truy cập thấp nhưng kích thước lớn. Vì vậy, khi chúng tôi đọc từng byte tệp 1Gb (nghĩa là chúng tôi truy cập vào ổ cứng HDD một tỷ lần), chúng tôi dành nhiều thời gian để làm việc với một thiết bị tốc độ thấp (chúng tôi chuyển từng hạt cát từ thân xe tải KamAZ vào hộp cát). Hãy cố gắng cải thiện nó hơn nữa. Hãy đổ cát ra khỏi TOÀN BỘ xe tải KAMAZ cùng một lúc!
một sự lạc đề nhỏ nhưng lại quan trọng .
Sử dụng bộ đệm
Kết quả chúng ta nhận được: file 46MB 0,08 giây (chưa đầy một giây). Tệp 1Gb - 0,9 giây (chưa đến một giây). Tệp 32Gb - 31 giây. Lưu ý rằng đối với tệp 1 Gb, chúng tôi đã cải thiện hiệu suất từ vài giờ xuống vài phần giây !!! Với thực tế khiêm tốn này, chúng tôi sẽ hoàn thành thử nghiệm và cải thiện mã ban đầu. Chúng tôi đã đạt được tiến bộ về nhiều mặt - chúng tôi hài lòng với các chỉ số mới về mức tiêu thụ bộ nhớ và thời gian hoạt động. Ngoài ra, trong trường hợp này, chúng tôi không lấy các bộ sưu tập vô dụng từ thư viện tiêu chuẩn. Tái bút Ai đó sẽ nói ví dụ này thật xa vời, v.v. Nhưng có rất nhiều nhiệm vụ tương tự - để phân tích một khối lượng lớn các phần tử có số lượng trạng thái hữu hạn. Ví dụ: hình ảnh (RGB - thường được lưu trữ trong 24 byte, trong trường hợp của chúng tôi long[] arrRGB = new long[256*256*256] sẽ chỉ chiếm 64MB trong bộ nhớ), âm nhạc (biên độ thường được số hóa thành 16 hoặc 24 bit ) hoặc cảm biến chỉ báo rời rạc, v.v. |