Mam do Was pytanie czy dopisywanie danych do pliku tekstowego za pomocą append jest ograniczone, gdyż wyskakuje mi błąd wejścia/wyjścia I/0 103 gdy plik osiąga powyżej 2GB dokładnie te samą wartość przy różnych danych. Jak rozwiązać ten problem ?
var
plik : TextFile;
begin
AssignFile(Plik, ExtractFilePath(Application.ExeName)+'Szablony\Dane.txt');
try
Append(plik);
Write(plik, Sl.Text);
Flush(plik);
finally
CloseFile(plik);
end;
Jak rozwiązać ten problem ?
Nie tworzyć pliku tekstowego wielkiego na 2 GB?
Serio, kto będzie go przeglądał?
Azarien uwierz mi, że ja. Chodzi o to, że są to dane z zakresu kombinacji bez powtórzeń ze statystyką 42/36 a więc ponad 5 mln kombinacji istotnych. Poźniej gdy mam taki plik mogę wyciągać dane na różne sposoby a nie od początku tworzyć 5245 786 kombinacji z danymi.
TFileStream (natomiast trzymanie 2 GB danych w pamięci jest złe...)
najrozsądziejszym rozwiązaniem by było podzielenie tego na kilka mniejszych plików - ułatwi to przeglądanie, przenoszenie (partycje FAT32 mają limit wielkości 4GB, a to wciąż popularny system plików np na pendrive'ach) itp.
ale widzę że są też biblioteki typu http://gp.17slon.com/gp/gphugefile.htm
nawet jeśli zapiszesz więcej to będziesz miał problem z przeglądaniem bo standardowa metoda seek przyjmuje signed int czyli ma limit do 2GB
Dane nie są ładowane do TStringList bo lapek by wybuchł są wyszukane z pliku dużego i około 2mb zapisanych do TStringList <- Patryk27
Też tak pomyślałem, aby podzielić ten plik na kawałki a następnie scalić. Jednak zależy mi na pliku w całości tworzenie takiego pliku zajmuje około 4h. Jednak problem pozostaje gdyż dopiero dane jednego pliku dają obraz rzeczywistości. A po podzieleniu musiałbym znowu przechodzić na nowe pliki i wiązać dane razem :(
A nie możesz zrobić pliku rekordowego?
Bruno(M) napisał(a):
Też tak pomyślałem, aby podzielić ten plik na kawałki a następnie scalić. Jednak zależy mi na pliku w całości tworzenie takiego pliku zajmuje około 4h. Jednak problem pozostaje gdyż dopiero dane jednego pliku dają obraz rzeczywistości. A po podzieleniu musiałbym znowu przechodzić na nowe pliki i wiązać dane razem :(
Ale po co je scalać w ogóle? Czemu nie możesz przyjąć kolejnego pliku jako sekcji pliku. Wystarczy dodać do aplikacji jedną warstwę abstrakcji więcej i w ogóle nie będzie różnicy czy to będzie w jednym czy w wielu plikach.
I czy naprawdę trzymasz te dane w postaci tekstu? Gdybyś zapisywał binarnie to plik zajmowałby z 10x mniej i w ogóle nie miałbyś tego problemu
Spróbuje to rozwiązać za pomocą innego typu zapisu i odczytu do pliku.
Może najpierw sprawdź czy na pewno generowanie zawartości tego pliku na bieżąco nie jest szybsze od czytania z pliku.
standardowa metoda seek przyjmuje signed int czyli ma limit do 2GB
Może w twoim środowisku. W FPC już jakiś czas temu przenieśli się na int64... Gdyby standardowe seek byłoby na intach, to TFileStream zapewne też by nie działało bo jest zaimplementowane zapewne na takim seek...
Gdybyś zapisywał binarnie to plik zajmowałby z 10x mniej i w ogóle nie miałbyś tego problemu
IMO jeżeli ktoś trzyma tyle danych, to warto rozważyć jakąś wydajną bazę danych która służy do przechowywania danych.
Same 5 mln kombinacji wykonuje się w "mig". Tzn w zaledwie 2 min. A pod obciążeniem plik standardowo generuje się w około 4h. Jak się okazuje problem nie wynika z braku otwarcia a jedynie z zamknięcia - closefile. Pętla wykonuje się bardzo szybko i zanim kursor ustawi się na koniec. Dodawane są kolejne dane. Czy zastosowanie sleep będzie dobrym rozwiązaniem podczas appendowania ? Zdaje sobie że czas się wydłuży w zależności od czasu użytego w sleep.
To nie lepiej nie zamykać pliku dopóki nie zapiszesz wszystkiego? Odpadną Ci 3 najbardziej czasochłonne operacje (otwarcie pliku, przejście na koniec, zamknięcie).
Bruno(M) napisał(a):
Same 5 mln kombinacji wykonuje się w "mig". Tzn w zaledwie 2 min. A pod obciążeniem plik standardowo generuje się w około 4h.
Czegoś chyba nie rozumiem. Jeżeli dane generujesz i nie zapisujesz to masz 2 min, zaś jeżeli dane generujesz i zapisujesz to 4h, czy dobrze zrozumiałem?
Bo jeżeli tak to nie tędy droga.