Wczytanie bardzo dużego pliku txt

Odpowiedz Nowy wątek
2015-01-01 18:46
PAV
0

Witam,

Mam pewien problem związany plikiem txt o rozmiarze 10 GB (zawiera 181 milionów linii tekstu). Pliku takiego nie da się otworzyć standardowym edytorem tj. notepad czy Notepad++. W związku z tym chciałem wczytać go programowo i podzielić na kilkadziesiąt mniejszych plików, które następnie będzie można przejrzeć i poddać dalszej analizie. Problemem jaki mam jest czas potrzebny na podział. Próbowałem różnych strategii: włącznie z czytaniem pliku przez wiele wątków niezależnie od siebie (tzn. jeden wątek wczytuje i dzieli część od linii 0 do linii 100 000, drugi od 100 001 linii do 200 000 linii itd). W przypadku pracy na wielu wątkach widać pewne przyspieszenie, ale wciąż czas potrzebny na przetworzenie takiej ilości danych jest strasznie długi (na mocnej maszynie wyszło mi że musiałbym czekać na wynik kilka dni). Czy istnieje jakaś opcja, która pozwoliłaby dokonać takiej operacji w sensownym czasie (np. kilka godzin/1 dzień)? Czy też może należy wykonać takie zadanie w innym języku programowania niż C#?

Pozdrawiam.

Pozostało 580 znaków

2015-01-01 20:13
0

Myślę, że można by linuxowe dd do tego wykorzystać i mieć w kilka minut gotowe.
Edit: chociaż nie, z tego co wiem liniami nie można, musiałbyś wyczaić offsety.


edytowany 2x, ostatnio: Patryk27, 2015-01-01 20:41

Pozostało 580 znaków

2015-01-01 20:16
0

Wątki mogą (choć nie muszą) nawet spowolnić pracę z plikiem. Musisz pamiętać o odpowiedniej wartości FileAccess i FileShare.
Możesz pokazać fragment kodu którym kopiujesz tekst? Jakoś nie chce mi się wierzyć że jest aż tak wolny.


szogun

Pozostało 580 znaków

2015-01-01 20:30
1

Tak z ciekawości stworzyłem program który tworzy duży plik, nie chciało mi się czekać na stworzenie większego ale 18mln linii, zajęło 1.8 Gb pamięci i stworzyło się to w 1min. Więc nie wydaje mi się aby odczyt + zapis był aż tak wolny.

1.8Gb masz na myśli dysk a nie RAM? - szogun1987 2015-01-01 20:33
Oczywiście dysk. - dam1an 2015-01-01 20:35

Pozostało 580 znaków

2015-01-01 22:25
1

Jest kilkanaście sposobów na odczytanie pliku, skąd mamy wiedzieć, którego Ty użyłeś i czemu tak wolno działa, skoro nie pokazałeś kodu?

Sensowny czas tej operacji jest mniejszy niż 10 minut.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 1x, ostatnio: somekind, 2015-01-01 22:26

Pozostało 580 znaków

2015-01-01 22:31
0

Uwaga, odpalam swoją magiczną kulę!

Skoro dodanie wątków do czytania w wielu miejscach przyspieszyło wykonywanie zadania oznacza to tyle, że wykonujesz operacje na bieŻąco (Boże, widzisz takie błędy i nie grzmisz) dla wczytanych danych blokując wczytywanie.

Jeden wątek zajmuje się czytaniem, drugi pisaniem. Tyle ma się dziać.

edytowany 1x, ostatnio: spartanPAGE, 2015-01-01 22:31
też się będą gryzły - chyba że będą to dwa osobne dyski - abrakadaber 2015-01-01 23:05

Pozostało 580 znaków

2015-01-01 23:04
3
  1. ustalasz po ile MB chcesz mieć pliki (dalej x MB)
  2. kopiujesz z głównego pliku (dalej g) x MB blokami po np. 1024b
  3. szukasz w g pierwszego znaku nowej linii
  4. do ostatniego pliku x MB doklejasz na końcu resztę ostatniej linii
  5. goto 1 aż skończy Ci się plik g

Na pewno będzie szybsze niż szukanie każdego końca linii i ich zliczanie. Wada to to, że będziesz miał różną ilość linii ale zbliżony rozmiar każdego kawałka


Chcesz pomocy - pokaż kod - abrakadabra źle działa z techniką.
Też to chciałem powiedzieć ale to jest plik tekstowy kopiowanie blokami bajtów może rozerwać znak na 2 części. Jeżeli jest to tekst w ASCII, albo w innym kodowaniu o stałej ilości bajtów na znak to ok, ale w Unicode znaki ASCII są kodowane 1 bajtem, polskie i inne odchyły od łacińskiego alfabetu 2-ma bajtami, chińskie krzaczki już 3-ma - szogun1987 2015-01-02 20:46
w moim algorytmie nie może - zawsze do końca kopiowanego bloku doklejane są znaki (bajty) aż do znaku końca linii - nawet jeśli jakiś unicodowy znak "rozerwie" się na pół z powodu kopiowania stałej ilości bajtów to w następnym kroku zostanie on znowu sklejony - abrakadaber 2015-01-02 23:26

Pozostało 580 znaków

2015-01-02 00:05
0

Pliku takiego nie da się otworzyć standardowym edytorem tj. notepad czy Notepad++. W związku z tym chciałem wczytać go programowo i podzielić na kilkadziesiąt mniejszych plików, które następnie będzie można przejrzeć i poddać dalszej analizie.

Pytanie na czym ma polegać ta analiza.
Taki klawisz F3 pod Total Commanderem jest w stanie wyświetlić wielki plik.

Pozostało 580 znaków

2015-01-02 00:24
Złoty Krawiec
0

@Azarien, dlaczego Total jest zdolny, a inne edytory nie? Przecież żeby coś wyświetlic konieczne jest włożenie do pamięci, a tyle nie włożymy do pamięci.
podro

Pozostało 580 znaków

2015-01-02 00:25
0
Złoty Krawiec napisał(a):

@Azarien, dlaczego Total jest zdolny, a inne edytory nie? Przecież żeby coś wyświetlic konieczne jest włożenie do pamięci, a tyle nie włożymy do pamięci.
podro

Nie musisz wkładać od razu do pamięci całego pliku - wystarczy tyle, ile jest wyświetlone na ekranie.

Pozostało 580 znaków

2015-01-02 00:34
0
Złoty Krawiec napisał(a):

@Azarien, dlaczego Total jest zdolny, a inne edytory nie? Przecież żeby coś wyświetlic konieczne jest włożenie do pamięci, a tyle nie włożymy do pamięci.
podro

bo pod F3 masz PODGLĄD a nie edycję i możesz mieć w pamięci tylko to co pokazujesz nie przejmując się resztą


Chcesz pomocy - pokaż kod - abrakadabra źle działa z techniką.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0