Làm thế nào để Windows xác định mất bao lâu để thực hiện một hành động nhất định trên một tệp?

Tôi muốn biết liệu có một phương trình mà Windows sử dụng để xác định mất bao lâu để thực hiện một hành động trên một tệp, nói xóa, sao chép, xóa hoặc cài đặt.

nhập mô tả hình ảnh ở đây

Ví dụ: khi tôi xóa một tệp và Windows cho biết "Thời gian còn lại: 18 giây" cách tính số này và sử dụng cái gì?

windows file-transfer file-management

— yuritsuki
nguồn

Vì con số này thường xuyên bị sai, nên việc đoán dựa trên các tệp # để xóa, kích thước và tốc độ xóa được tính theo thời gian để tăng hoặc giảm dự đoán.

— gian mạng

@Ramhound Và làm thế nào để biết nó mất nhanh như thế nào? Đây có phải là biến tĩnh giống nhau cho tất cả các máy khác, bao gồm cả các máy chạy trên SSD, HD không? Nếu tôi có 200 GB ram thì sao? Nếu tôi có 10 MB RAM thì sao? Làm thế nào để tính toán mức độ "nhanh" của một hành động?

— yuritsuki

@imreallyfamecore Chà, ý tưởng cơ bản là nó đo tốc độ của nó trong vài giây và giả định rằng phần còn lại của quá trình sẽ tiếp tục với tốc độ trung bình. Nếu tốc độ trung bình thay đổi theo thời gian, nó sẽ điều chỉnh ước tính (dẫn đến "Windows nói với tôi rằng nó sẽ được sao chép sau 10 phút và đã 2 giờ rồi!"). Tuy nhiên, đó chỉ là dự đoán - không có cách nào để HĐH hoặc bất kỳ ứng dụng nào biết được nó sẽ thực sự mất bao lâu. Nếu ổ cứng bị hỏng thì sao? Hoặc bạn đang chuyển qua mạng? Hoặc có rất nhiều phân mảnh?

— Luaan

Tôi biết tôi sẽ bị trừng phạt vì điều này, nhưng tôi không thể tự giúp mình. Đây không phải là câu trả lời của bạn. XKCD: Ước tính

— KlaymenDK

Mã:timeLeft = random(1,100);

— MadTux 16/07/14

Câu trả lời:

Bạn có nhận thấy rằng thường thì nó không cung cấp cho bạn bất kỳ ước tính nào trong những giây đầu tiên không?

Đó là bởi vì trong những giây đầu tiên, nó chỉ thực hiện thao tác mà nó phải thực hiện. Sau đó, sau một thời gian (nhỏ), nó biết nó đã được sao chép / xóa / v.v. và mất bao lâu . Điều đó cung cấp cho bạn tốc độ trung bình của hoạt động.

Sau đó, chia các byte còn lại cho tốc độ và bạn sẽ có thời gian để hoàn thành thao tác.

Đây là môn toán tiểu học. Nếu bạn muốn đi du lịch 360 km, và vào cuối phút đầu tiên bạn đã đi được 1 km, bạn sẽ mất bao nhiêu để đến đích?

Chà, tốc độ là 1 km / phút. Đó là 60 km / h. 360 km chia cho 60 km / h mang lại cho bạn 6 giờ (hoặc 360 km / 1 km / phút = 360 phút = 6 giờ). Vì bạn đã đi được một phút rồi nên thời gian ước tính còn lại là 5 giờ 59 phút.

Thay thế "du lịch" bằng "bản sao" và "km" bằng "byte" và đó là câu hỏi của bạn.

Các hệ thống khác nhau có cách ước tính thời gian khác nhau. Bạn có thể mất phút cuối và các ước tính có thể thay đổi dữ dội hoặc bạn có thể mất toàn thời gian và nếu tốc độ thực sự thay đổi vĩnh viễn, ước tính của bạn có thể khác xa với thực tế. Những gì tôi mô tả là phương pháp đơn giản nhất.

— Valmiky Arquissandas
nguồn

Chỉ cần làm rõ: Bạn có khẳng định rằng đây là cách Windows thực hiện không? Hay bạn chỉ đang minh họa một số số học đơn giản bằng cách có thể nhận được câu trả lời?

— Shredderroy

và cuối cùng 1%phải mất time so far * rand[0 - 10]trong khi hiển thịfew seconds left

— Đánh dấu

Nếu bạn quan tâm, câu hỏi này sẽ cho bạn biết Windows (và OSX) định dạng thời gian còn lại vào thanh tiến trình như thế nào khi nó có ý tưởng về thời gian còn lại ux.stackexchange.com/q/23624

— Richard

Tôi không nói đây là cách Windows làm điều đó. Nếu nó làm chính xác như thế này, đó là một sự trùng hợp. Có vẻ như nó là như vậy, nhưng đây là một cách mà có thể có được câu trả lời. Tôi nhận thấy rằng người đăng muốn biết làm thế nào được thực hiện và Windows được đưa ra làm ví dụ. Một hằng số phù hợp một kích thước nhân với kích thước còn lại (như ông đề xuất) là hoàn toàn không khả thi và tôi nghĩ rằng nó tiết lộ rằng ông không biết làm thế nào những ước tính này được thực hiện.

— Valmiky Arquissandas

@ValmikyArquissandas: Raymond Chen (một nhà phát triển trong nhóm Windows tại Microsoft) xác nhận thuật toán này trong một bài đăng trên blog của anh ấy và cũng giải thích tại sao nó có thể sai. blog.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx

— Richard

Tôi nghĩ rằng việc trả lời bằng một phép nhân chéo đơn giản là hết sức ủy khuất, tôi chắc chắn rằng anh ấy đã biết rằng, đó là cách chúng tôi liên tục đoán ra những điều trong đầu.

Vấn đề với các thanh tiến trình hoạt động tệp là nó chỉ đúng với dữ liệu thống nhất, vì vậy nếu bạn sao chép 100 tệp có cùng kích thước và ổ đĩa của bạn không làm gì khác, thì tiến trình ước tính sẽ được phát hiện, nhưng nếu trước tiên 99 tệp là các tệp txt nhỏ và tệp cuối cùng là tệp video lớn? Tiến độ sẽ được CÁCH.

Vấn đề này tiếp tục gia tăng khi bạn không xử lý tệp trong một thư mục, nhưng nhiều thư mục phụ. Giả sử bạn có 5 thư mục con và bạn muốn xóa chúng (kích thước không thành vấn đề trong trường hợp này), 4 thư mục đầu tiên chỉ chứa ít hơn 10 tệp, do đó, khi thao tác đến thư mục thứ 5, nó nghĩ rằng đó là về Đã hoàn thành 80% và thư mục boom 5 chứa 5000 tệp và tiến trình của bạn nhảy trở lại 1%

WinXP đã cố gắng khắc phục điều này bằng cách đếm số lượng tệp trước đó có nghĩa là khi thư mục không được lập chỉ mục trong cửa sổ, tùy thuộc vào số lượng tệp, XP không thực sự bắt đầu hoạt động trong 20 giây đầu tiên (thời gian cần thiết đếm) khiến mọi người tức giận.

Vì vậy, trong khi tôi cũng không có kiến thức đặc biệt về cách Windows thực hiện (nhưng còn gì khác ngoài việc đếm tệp và byte) Tôi hy vọng tôi có thể minh họa tại sao nó không hoàn hảo và tại sao nó không bao giờ hoàn hảo.

Điều tốt nhất bạn có thể làm là không chỉ dựa vào filecount HOẶC bytecount, mà xây dựng trung bình trong số hai.

Hoặc nếu bạn muốn phát điên thêm nữa, HĐH có thể bắt đầu một cơ sở dữ liệu về thời gian các hoạt động này diễn ra trong quá khứ trên máy của bạn và đưa yếu tố đó vào phương trình.

Suy nghĩ cuối cùng: Nếu ai đó nghĩ về một hệ thống tập tin sẽ cho HĐH biết kích thước của mỗi thư mục, mà không tính toán trước, ít nhất bạn sẽ có được ước tính tiến độ chính xác khi xóa toàn bộ thư mục và không chỉ các phần của nó.

— Troik
nguồn