Zastanowiło mnie usuwanie plików w KDE4. A raczej przenoszenie, chociaż usuwanie też nie poraża szybkością. Proste testy naoczne wykonałem. Przed każdym testem stworzyłem 5000 plików:
$ for i in {1..5000}; do touch "$i"; done
I teraz proste eksperymenty:
rm -f *— time powiedział że 0.092s total.mc, * (zaznaczenie) i F8 — na oko mniej niż 0.25s.- Dolphin/KDE4, S-Del (usuwanie) — około 3s (WTF? 300 razy wolniej niż
rm). - Dolphin/KDE4, Del (przenoszenie do kosza) — około 121s! WTF³? 12000+ razy wolniej niż
rm?. Ile można tracić czasu narename()i dodanie jakiejś meta-informacji gdzieś tam do jakiegoś pliku?
Więc to stąd biorą się konsolowcy, którzy nie lubią interfejsów graficznych pod GNU…
Kategorie:
Technorati:
23 komentarze do wpisu WTF KDE4?
zergu
Albo kosz na innej partycji, albo ktoś wódkę pił podczas klepania kodu. ;-)
mcv
Patrycja ta sama. Ciekawostka, że jak przesuwa do kosza, to oba rdzenie wykorzystuje na 100% (w dwóch wątkach to robi?).
mh
Może to nie jest zwykłe rm, tylko shred -n DUZA_WARTOSC ? :)
fluxid
kde ssie :)
mcv
To nie jest shred, bo to przenoszenie do kosza. Swoją drogą, stare KDE (w okolicach 2 chyba) miało obok „Usuń” również „Zniszcz”. I shredowało. Potem wywalili. Chyba uznali, że będzie zbyt trudne dla użytkownika.
Livio
To raczej bierze się stąd, że Dolphin komunikuje się jeszcze (pośrednio) z Plasmą, liczy każdą operację itp.
W ogóle, z ogromem małych plików zawsze jest większy problem niż z kilkoma niewielkimi. I wynika to chyba właśnie z głupoty obliczania ilości plików.
mcv
Jakby rzeczywiście liczył, to powinien chociaż jakiś użytek z tego zrobić, np. w postaci progress-bara. Teraz jest taki progress-bar latający w lewo i w prawo. ;-)
bnc1
"Dolphin/KDE4, S-Del (usuwanie) — około 3s (WTF? 300 razy wolniej niż rm)."
Pomyliłeś się, 30 razy wolniej, nie 300.
mcv
Faktycznie. I nie 12000 tylko 1200.
Paweł Ciupak
To bierze sie z tego samego powodu, jak np. to, że 'rm -rvf /' jest wolniejsze niż 'rm -rf /'.
mcv
Trochę za dużo tego czasu schodzi na to -v. Zwłaszcza że etykieta z aktualnie przenoszonym plikiem aktualizuje się co N plików, nie co każdy jeden.
mcv
Przy kasowaniu (S-del) Dolphin nie wyświetlił żadnego dialogu, tylko przymulił się z całym swoim oknem. Jednak gdy nie kasuję plików ze środka katalogu, tylko cały katalog (nie rozwinięty w tree-view), to kasowanie idzie deczko szybciej. Możliwe że Dolphin odświeża listę co każdy plik. Tych odświeżeń i tak jednak nie widać, bo całe okno jest zmulone (może nie wraca podczas kasowania ani razu do głównej pętli Qt?).
SebaS86
Przypadłość każdego interfejsu graficznego (zdaje się, że to był również jeden z zarzutów do pierwszych wersji Visty - i w sumie nadal działa ociężale ;)).
Co do usuwania do kosza - nie zapominaj, że trzeba zapewnić możliwość przetrzymywania kilku wersji plików o tej samej nazwie, tak przynajmniej działają porządne kosze.
rozie
Zrobiłeś trochę błąd w założeniach i porównujesz nieporównywalne - nie powinieneś porównywać rm -f * z usuwaniem z gui, tylko pewnie (minimum) for i in {1..5000}; do rm "$i"; done Sam piszesz, że dodatkowo wchodzi w grę "jakieś rename" i "dodanie jakichś metainformacji"... To nie są równoważne czynności. Plus, kasowanie 5k plików to nie jest coś, pod co się gui optymalizuje. Gui raczej ma być łatwe i intuicyjne (gimme intuicyjnego basha/sh o identycznej funkcjonalności to pogadamy ;-)).
Livio
Przyblokowanie Dolphina to pewnie brak osobnego wątku dla usuwania.
A co do paska postępu, nie zauważyłem nic latającego od prawej do lewej i nazad, u mnie wyskakuje powiadomienie o postępie Plasmy z ładnym paskiem. Może to dlatego, że mam KDE... Zaraz, która to wersja... 4.4.5.
mcv
Też mam 4.4.5. Żadne powiadomienie nie wyskakuje, tylko osobne okno dialogowe. Przy usuwaniu natomiast nic nie wyskakuje.
rozie: W grę wchodzi tylko rename (rename jest szybsze niż unlink) i dopisanie czegoś w jakimś pliku z meta-informacjami. To nie może aż tak boleć, biorąc pod uwagę że system te zapisy powinien cache'ować, ba, można całą tę informację zapisać za jednym razem na początku bądź na końcu przenoszenia. Nie przypominam sobie, by KDE 3.5 tak muliło.
SebaS86
I właśnie cache tutaj może zawieść, bo wszelkiej maści narzędzia graficzne potrzebują przelecieć przez strukturę co najmniej dwa razy - do zliczenia i późniejszego usunięcia wszystkich elementów (zresztą widać już na przykładzie mc różnicę). Dodatkowo dochodzi koszt GUI, które może być odświeżane co plik (teraz wyobraź sobie CPU generujące teksturę, później na chwilę trzeba oddać magistralę aby skopiować nową teksturkę do pamięci karty graficznej). No i być może KDE gdzieś sobie trzyma informacje o plikach (miniatury, ostatnio otwierane dokumenty), które trzeba na wszelki wypadek przejrzeć i uaktualnić. Proste usuwanie nie musi być trywialną operacją.
mcv
Ani mc ani Dolphin nie musi nic zliczać, bo ma już wszystko zaznaczone, a katalogów tam nie ma (ale może zlicza, nie wiem; przy przenoszeniu do kosza jednak Dolphin/KDE nie wyświetla u mnie normalnego paska postępu). Dlaczego cache miałby nie działać w tym przypadku?
GUI natomiast nie odświeża nic co plik. Przy usuwaniu plików w ogóle nic kompletnie nie rysuje, natomiast przy przenoszeniu do kosza odświeżenie etykiety jest co jakieś 10 plików (4..5 razy na sekundę około; wychodzi jakieś 43 usuwane pliki na sekundę). Oczywiście pasek postępu lata w te i we wte, pewnie z 10 klatek na sekundę. Ale to i tak jest znikome zużycie CPU i nie ma prawa aż tak spowalniać całej operacji. W tle pewnie jakieś cuda są robione, bo oba rdzenie są zużyte na 100%, ale IO do dysku praktycznie nie ma żadnego.
Ciekawy bug znalazłem teraz. Zrobiłem sobie N plików, zacząłem przenosić do kosza, przerwałem. Dolphin nie odświeżył listy. Teraz chciałem usunąć i nie zauważyłem żadnej reakcji. Dopiero po chwili na dole w pasku statusu zauważyłem komunikat, że „nie można usunąć pliku /home/mcv/t/1.”
mcv
„Dlaczego cache miałby nie działać w tym przypadku?” — oczywiście chodzi mi o przypadek kiedy programy faktycznie zliczają pliki.
SebaS86
Jasne, że musi zliczać, bo "funkcja" do usuwania potrzebuje wiedzieć czy przypadkiem nie zaznaczyłeś katalogu i nie trzeba przelecieć rekurencyjnie w głąb. A cache może nie działać bo może ulec przedawnieniu bądź przepełnieniu i część informacji i tak będzie trzeba wczytać od początku.
Chociaż w sumie dyskusja robi się bez sensu, najlepiej będzie spytać się autorów programu, co on tam jeszcze robi w tle, bo na razie rzucamy tutaj tylko bezpodstawne oskarżenia i wysnuwamy czysto hipotetyczne teorie, a prawda jest taka, że KDE to jakby nie patrzeć kawał skomplikowanego kodu.
mcv
No to jako że u mnie te eksperymenty są powtarzalne, pliki są puste (więc nie zajmują buforów tylko właśnie co najwyżej cache), a IO praktycznie nie widzę przy przenoszeniu plików, nieśmiało wnioskuję że cache nie zawodzi.
Mógłbym oczywiście popatrzeć w kod i wszystko bym wtedy wiedział, gdyby nie fakt, że mi się nie chce. :D No ale samo znalezienie odpowiedzialnego (odpowiedzialnych) kodów pewnie by mi dużo zajęło. Wolę więc pogdybać.
SebaS86
MVC, plik może być pusty ale w pamięci prawdopodobnie zajmuje tyle ile struktura na dysku (zależne od implementacji konkretnego systemu plików, dla EXT może to być nawet kilka bloków), zresztą już sama nazwa pliku nie jest zerowa, do tego prawa dostępu, lista uchwytów do czytania, zapisu, do tego przemnożone przez setki otwartych plików przez różne usługi systemowe, programy działające w tle, pamięć podręczna może zawieść w najmniej oczekiwanym miejscu. :)
Zgodzę się też z Rozie odnośnie "kasowanie 5k plików to nie jest coś, pod cwo się gui optymalizuje", środowisko typu KDE optymalizuje się pod kolekcjonowanie i wyszukiwanie plików (siłą rzeczy inne operacje przez to stają się wolniejsze). Pliki użytkownika powinny istnieć z założenia jak najdłużej, gdyż przechowują istotne dla niego informacja. W końcu używa swojej maszyny aby magazynować i przetwarzać w użyteczny dla siebie sposób dane, nie po to aby je niszczyć.
mcv
Zawartość pliku leci do buforów, meta-dane (i-node) leci do cache. Jeśli jest wolny RAM, to jest miejsce na oba. Wystarczy zamknąć jakiś program i trochę RAM-u się zwolni, w sam raz dla buforów/cache. Jak wiesz, cache działa dla wszystkich programów, nie tylko dla rm czy mc. :-) Poza tym, jak już pisałem, to co mi wychodziło jest powtarzalne.