W jaki sposób system Windows określa, ile czasu zajmuje wykonanie danej akcji na pliku?

Chciałem wiedzieć, czy istnieje równanie, którego system Windows używa do określenia, ile czasu zajmuje wykonanie pliku, powiedzmy usunąć, skopiować, skasować lub zainstalować.

wprowadź opis zdjęcia tutaj

Na przykład, kiedy usuwam plik, a system Windows mówi „Pozostały czas: 18 sekund”, jak oblicza ten numer i jakiego używa?

windows file-transfer file-management

— yuritsuki
źródło

Ponieważ liczba ta jest często niepoprawna, jest ona zgadywana na podstawie # plików, które należy usunąć, rozmiar i szybkość usuwania są odpowiednio zwiększane lub zmniejszane.

— cybernard

@Ramhound A skąd ma wiedzieć, jak szybko to zajmuje? Czy jest to ta sama zmienna statyczna dla wszystkich innych maszyn, w tym tych, które działają na dyskach SSD i HD? Co jeśli mam 200 GB pamięci RAM? Co jeśli mam 10 MB pamięci RAM? Jak oblicza się, jak „szybkie” jest działanie?

— yuritsuki

@imreallyfamecore Cóż, podstawową ideą jest to, że mierzy to, jak szybko jedzie przez kilka sekund, i zakłada, że reszta procesu będzie kontynuowana średnio z tą samą prędkością. Jeśli średnia prędkość zmienia się w czasie, dostosuje oszacowanie (prowadząc do niesławnego „Windows powiedział mi, że zostanie skopiowane za 10 minut, a minęły już 2 godziny!”). To tylko przypuszczenie - system operacyjny ani żadna aplikacja nie mają pojęcia, jak długo to zajmie. Co się stanie, jeśli dysk twardy zostanie uszkodzony? A może przesyłasz przez sieć? Czy jest dużo fragmentacji?

— Luaan,

Wiem, że zostanę za to ukarany, ale nie mogę się powstrzymać. To NIE jest twoja odpowiedź. XKCD: Szacowanie

— KlaymenDK

Kod:timeLeft = random(1,100);

— MadTux,

Odpowiedzi:

Czy zauważyłeś, że zwykle nie daje to żadnych szacunków w pierwszych sekundach?

To dlatego, że w pierwszych sekundach wykonuje tylko operację, którą musi wykonać. Następnie, po (krótkim) czasie, wie, ile już skopiował / usunął / etc i jak długo to trwało . To daje średnią prędkość operacji.

Następnie podziel pozostałe bajty przez prędkość, a będziesz miał czas, aby ukończyć operację.

To matematyka w szkole podstawowej. Jeśli chcesz przejechać 360 km, a pod koniec pierwszej minuty przejechałeś 1 km, ile zajmie ci dotarcie do miejsca docelowego?

Prędkość wynosi 1 km / minutę. To 60 km / h. 360 km podzielone przez 60 km / h daje 6 godzin (lub 360 km / 1 km / minutę = 360 minut = 6 godzin). Ponieważ podróżowałeś już przez minutę, szacowany pozostały czas to 5 godzin i 59 minut.

Zamień „podróż” na „kopiuj” i „km” na „bajty” i to jest twoje pytanie.

Różne systemy mają różne sposoby szacowania czasu. Możesz zająć ostatnią chwilę, a prognozy mogą się bardzo różnić lub możesz zająć cały czas, a jeśli prędkość faktycznie zmieni się na stałe, twoje prognozy mogą być dalekie od rzeczywistości. To, co opisałem, jest najprostszą metodą.

— Valmiky Arquissandas
źródło

Tylko dla wyjaśnienia: Czy twierdzisz, że tak właśnie działa system Windows? A może jedynie ilustrujesz prostą arytmetykę, za pomocą której można uzyskać odpowiedź?

— Shredderroy

a za ostatni 1%trwa time so far * rand[0 - 10]podczas wyświetlaniafew seconds left

— Mark

Jeśli jesteś zainteresowany, to pytanie powie Ci, jak system Windows (i OSX) formatuje czas w lewo na pasku postępu raz ma pomysł, jak długo są pozostałej ux.stackexchange.com/q/23624

— Richard

Nie twierdzę, że tak właśnie działa system Windows. Jeśli zrobi to dokładnie tak, to zbieg okoliczności. Wygląda na to, że tak jest, ale w ten sposób można uzyskać odpowiedź. Przyszło mi do głowy, że plakat chciał wiedzieć, jak to się robi, a Windows podano jako przykład. Stała „jeden rozmiar dla wszystkich” pomnożona przez pozostały rozmiar (jak zaproponował) jest całkowicie niemożliwa i myślę, że ujawniło to, iż nie miał pojęcia, w jaki sposób dokonano tych oszacowań.

— Valmiky Arquissandas

@ValmikyArquissandas: Raymond Chen (programista w zespole Windows w Microsoft) potwierdza ten algorytm we wpisie na swoim blogu, a także wyjaśnia, dlaczego może być źle. blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx

— Richard

odpowiadanie prostym pomnożeniem krzyżowym jest okropnie protekcjonalne. Myślę, że jestem pewien, że już o tym wiedział. W ten sposób nieustannie zgadujemy, co dzieje się w naszej głowie.

Problem z paskami postępu operacji na plikach polega na tym, że są one poprawne tylko dla jednolitych danych, więc jeśli skopiujesz 100 plików, które mają ten sam rozmiar, a dysk nie robi nic innego, szacowany postęp będzie zauważalny, ale co jeśli pierwszy 99 plików to małe pliki TXT, a ostatni to duży plik wideo? Postęp będzie WOLNY.

Problem ten nasila się, gdy nie zarządzasz plikami w jednym folderze, ale w wielu podfolderach. Załóżmy, że masz 5 podfolderów i chcesz je usunąć (wtedy rozmiar nie ma większego znaczenia), pierwsze 4 foldery zawierają tylko mniej niż 10 plików, więc zanim operacja dotrze do 5. folderu, o którym myśli, że chodzi o 80% zrobione, a boom 5. folder zawiera 5000 plików, a twoje postępy wracają do 1%

WinXP próbował obejść ten problem, licząc wcześniej liczbę plików, co oznaczało, że kiedy folder nie był indeksowany w systemie Windows, w zależności od liczby plików, XP tak naprawdę nie zaczął operacji przez pierwsze 20 sekund (czas potrzebny na to hrabia), co doprowadziło wszystkich do wściekłości.

Więc chociaż nie mam specjalnej wiedzy na temat tego, jak to robi Windows (ale co tam jeszcze oprócz liczenia plików i bajtów), mam nadzieję, że zilustruję, dlaczego jest wadliwy i dlaczego nigdy nie będzie idealny.

Najlepsze, co możesz zrobić, to nie polegać wyłącznie na liczbie plików LUB liczbie bajtów, ale zbudować średnią z tych dwóch.

Lub jeśli chcesz się bardziej zwariować, system operacyjny może uruchomić bazę danych na temat tego, jak długo te operacje trwały w przeszłości na twoim komputerze i uwzględnić to w równaniu.

Ostatnia myśl: jeśli ktoś pomyśli o systemie plików, który poinformowałby system operacyjny o rozmiarze każdego folderu, bez jego wcześniejszego obliczenia, uzyskałbyś przynajmniej poprawne oszacowanie postępu podczas usuwania całych folderów, a nie tylko ich części.

— Troik
źródło