Autor Wątek: Jeden duży plik vs kilkaset małych.  (Przeczytany 4251 razy)

Offline BTM

  • Użytkownik

# Maj 15, 2007, 09:16:52
Takie małe pytanko - jakie są zalety trzymania wszystkich danych programu ( tekstury, modele, dźwięki, konfigi, filmy, etc. ) w jednym pliku - np. ID'owym pk3  (tak, wiem, że to ZIP) czy innych, własnych formatach, zamiast trzymać to w drzewie katalogów.

Tak na chłopski rozum, to widzę większe wady niż zalety - trzeba pisać algorytmy wyciągające konkretne pliki, wyciągać je i tak na zewnątrz, bo w RAM'ie wszystkiego trzymać nie ma sensu więc pewnie następuje spadek wydajności - ale może ktoś mnie poprawi?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Charibo

  • Redaktor

# Maj 15, 2007, 10:12:47
Trzymając wszystkie pliki w pliku zasobów tracisz chwilę czasu na rozpakowywanie ich (ale to przed pętla real-time najczęściej) ale zyskujesz miejsce na dysku dzięki korpesji. Ogólnie, zależy od cech projektu jak to zrobisz.

Offline Sivert

  • Użytkownik

# Maj 15, 2007, 10:14:03
To nie takie proste jak się wydaje. Małe pliki zamują więcej miejsca na dysku. 10.000 plików po 1 bajt zajmie na dysku nie ~10 KB (licząc same dane bez wpisów plików) a zależnie od partycji i rozmiaru klastra zajmie i ~40 MB (wiem, że przy obecnych dyskach to nic, ale zawsze). Jeden plik bez kompresji zajmie mniej miejsca, a przecież można użyć choćby zlib i skompresować wszystko.

Czasem pakując pliki autor chce ukryć tekstury, muzyke, shadery i inne pliki przed ludźmi.

Inna sprawa spróbuj przerzucić katalog mający 10.000 plików a mający jeden nawet większy plik - co trwa krócej ?

Za i przeciw jest wiele musisz sam zdecydować co wolisz.

EDIT: Miało być 10 KB nie MB, 40 MB zostaje bez zmian.
« Ostatnia zmiana: Maj 15, 2007, 23:51:15 wysłana przez Sivert »

Offline Charibo

  • Redaktor

# Maj 15, 2007, 10:14:45
Trzymając wszystkie pliki w pliku zasobów tracisz chwilę czasu na rozpakowywanie ich (ale to przed pętla real-time najczęściej)  Oczywiście potem nie na już różnicy, ale zyskujesz miejsce na dysku dzięki korpesji. Ogólnie, zależy od cech projektu jak to zrobisz.

truman

  • Gość
# Maj 15, 2007, 10:23:53
To nie takie proste jak się wydaje. Małe pliki zamują więcej miejsca na dysku. 10.000 plików po 1 bajt zajmie na dysku nie ~10 MB (licząc same dane bez wpisów plików) a zależnie od partycji i rozmiaru klastra zajmie i ~40 MB
Lol. Jesli umiem liczyc to 10 000 bajtow to nie cale 10 KB. A skad wytrzasnales 40MB to nie mam pojecia.

Offline BTM

  • Użytkownik

# Maj 15, 2007, 11:04:10
To nie takie proste jak się wydaje. Małe pliki zamują więcej miejsca na dysku. 10.000 plików po 1 bajt zajmie na dysku nie ~10 MB (licząc same dane bez wpisów plików) a zależnie od partycji i rozmiaru klastra zajmie i ~40 MB
Lol. Jesli umiem liczyc to 10 000 bajtow to nie cale 10 KB. A skad wytrzasnales 40MB to nie mam pojecia.
Bo w zależności od wielkości klastra plik, zawierający 1kb danych, może zajmować "fizycznie" więcej niż ten 1 kb -  kliknij sobie właściwości dowolnego pliku - masz "rozmiar" i "rozmiar na dysku"

Rzeczywiście, przy przerzucaniu może być to wygodne, ale przerzucamy raczej tylko raz ( z płyty na hdd ) a reszta to już w gestii użytkownika.

Dzięki za odpowiedzi ;-)

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Maj 15, 2007, 11:40:36
Problem VFS był już bardzo obszernie omawiany tutaj niedawno - zachęcam do poczytania tego wątku: http://forum.warsztat.gd/index.php/topic,3290.0.html.

Offline Kamil Trzciński

  • Użytkownik

# Maj 15, 2007, 12:11:04
Lol. Jesli umiem liczyc to 10 000 bajtow to nie cale 10 KB. A skad wytrzasnales 40MB to nie mam pojecia.

na FAT32 klaster mial 4kB, czyli miales 10k plikow * 4kB (nawet jak plik mial 1b) = 40MB

truman

  • Gość
# Maj 15, 2007, 12:15:53

Offline Charibo

  • Redaktor

# Maj 15, 2007, 14:52:45
Cytuj
Inna sprawa spróbuj przerzucić katalog mający 10.000 plików a mający jeden nawet większy plik - co trwa krócej ?

Jesli kopiujesz pliki w ramach tej samej partycji, skopiowanie jednego pliku zajmie tyle co nic - wystarczy zmienic pojedynczy wpis w tablicy alokacji. Natomiast jesli kopiujesz pomiedzy roznymi partycjami to nie ma zupelnie zadnej roznicy (a raczej jest, ale kilka sekund), bo i tak musisz fizycznie przeniesc dane.

Offline shyha

  • Użytkownik
    • Shyha@Flickr

# Maj 15, 2007, 15:49:38
Cytuj
Inna sprawa spróbuj przerzucić katalog mający 10.000 plików a mający jeden nawet większy plik - co trwa krócej ?

Jesli kopiujesz pliki w ramach tej samej partycji, skopiowanie jednego pliku zajmie tyle co nic - wystarczy zmienic pojedynczy wpis w tablicy alokacji. Natomiast jesli kopiujesz pomiedzy roznymi partycjami to nie ma zupelnie zadnej roznicy (a raczej jest, ale kilka sekund), bo i tak musisz fizycznie przeniesc dane.

Miales na mysli chyba przenoszenie a nie kopiowanie?

Offline nameczanin

  • Użytkownik
    • devlog

# Maj 15, 2007, 16:09:59
To nie takie proste jak się wydaje. Małe pliki zamują więcej miejsca na dysku. 10.000 plików po 1 bajt zajmie na dysku nie ~10 MB (licząc same dane bez wpisów plików) a zależnie od partycji i rozmiaru klastra zajmie i ~40 MB
Lol. Jesli umiem liczyc to 10 000 bajtow to nie cale 10 KB. A skad wytrzasnales 40MB to nie mam pojecia.

W jednym sektorze nie zmiescisz wiecej jak jednego pliku. Koniec.

W kazdym badz razie - teraz rzadziej widze gry, gdzie jest cos tak porozpakowywane na zewnatrz, bo gry sa coraz wieksze i coraz wiecej plikow musza posiadac [jeszcze te shadery czasami, ech]. Glownie chodzi o instalacje. Jak uzytkownik czeka na zainstalowanie sie nowo kupionego produktu, to nie ma czekac 40 minut [Tony Hawk Pro Skater 3 chyba sie tak instalowal :D] na 1 CD, ale max 10 na jedna plytke DVD.

Ale jak ktos napisal - musisz wybrac cnote pomiedzy rozpakowywaniem plikow do grania, a instalacja tego. Poczytaj poza tym tamte linki podane wyzej :)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 15, 2007, 18:09:11
Cytuj
Takie małe pytanko - jakie są zalety trzymania wszystkich danych programu ( tekstury, modele, dźwięki, konfigi, filmy, etc. ) w jednym pliku - np. ID'owym pk3  (tak, wiem, że to ZIP) czy innych, własnych formatach, zamiast trzymać to w drzewie katalogów.
Główna zaleta to taka, że jest porządek i nikt niedoświadczony nie będzie w tym grzebać. Inną zaletą jes to, że w przypadku modów wystarczy dograć jeden plik (najczęściej VFS'y potrafią łączyć zawartość kilku plików w jedno drzewo katalogów). Największą wadą jednak jest utrudnienie w dostępie do plików, dlatego często podczas tworzenia gry korzysta się ze zwykłego systemu plików, a pakuje się to wszystko dopiero na sam koniec. Moje zdanie jest takie - póki robisz niewielkie projekty, nie warto się w to bawić. :)

Cytuj
Trzymając wszystkie pliki w pliku zasobów tracisz chwilę czasu na rozpakowywanie ich (ale to przed pętla real-time najczęściej) ale zyskujesz miejsce na dysku dzięki korpesji. Ogólnie, zależy od cech projektu jak to zrobisz.
Pliki nie muszą być skompresowane, więc wystarczy jedynie znaleźć długość i położenie pliku, skoczyć w to miejsce i czytać. :)

Cytuj
na FAT32 klaster mial 4kB, czyli miales 10k plikow * 4kB (nawet jak plik mial 1b) = 40MB
1. Rozmiar klastra w FAT32 zależy, o ile dobrze pamiętam, od rozmiaru partycji.
2. Nie "miał", a "ma", bo ja ciągle na takowym siedzę (jakoś nie mam zaufania do NTFS'a, bo o ile wiem, to nie ma jego publicznej specyfikacji). :)

Offline Liosan

  • Redaktor

# Maj 15, 2007, 22:58:57
Najlepszy IMHO bylby VFS mogacy czytac zarowno pliki z dysku, jak i z wlasnych archwiwow, i to jeszcze o roznym stopniu kompresji :P Szybkosc odczytu nie jest tak naprawde problemem. Po pierwsze, VFS ma przewage nad systemem dyskowym - wiekszosc (o ile nie wszystkie) plikow i katalogow bedzie read-only (i znanych w momencie tworzenia archiwum). Pozwala to na uzycie technik adresowania duzy szybszych niz B-drzewa, dajmy na to haszowania doskonalego. Po drugie, jakiekolwiek dekompresja i deszyfrowanie moze byc wykonywane rownolegle.

Liosan

PS. Bodajze w Beyond Good and Evil byl subtelny pliczek everything.stuff wielkosci ~2GB :P

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 16, 2007, 00:49:21
Cytuj
Pozwala to na uzycie technik adresowania duzy szybszych niz B-drzewa, dajmy na to haszowania doskonalego.
Tak, tylko po co, skoro zwykły std::map w zupełności wystarczy. :)