Odkryłem, że pisanie i odczytywanie natywnego formatu pliku mat staje się bardzo, bardzo powolne przy większych strukturach danych o wielkości około 1 GB. Dodatkowo mamy inne, nie-matlabowe oprogramowanie, które powinno być w stanie odczytywać i zapisywać te pliki. Więc chciałbym znaleźć alternatywny format do wykorzystania do serializacji struktur danych Matlab. Idealnie ten format byłby ...

  1. być w stanie przedstawić dowolną strukturę Matlab do pliku.
  2. mają szybsze operacje we/wy niż pliki mat.
  3. mieć biblioteki I/O dla innych języków, takich jak Java, Python i C++.
11
Sean McCauliff 26 wrzesień 2012, 04:50

2 odpowiedzi

Najlepsza odpowiedź

Uproszczenie struktur danych i użycie nowego formatu pliku MAT v7.3, który jest wariantem HDF5, może być najlepszym rozwiązaniem. Format HDF5 jest otwarty i zawiera już biblioteki we/wy dla innych języków. W zależności od struktury danych mogą być szybsze niż stare binarne pliki mat.

  • Uprość struktury danych, które zapisujesz, preferując duże tablice prymitywów zamiast złożonych struktur kontenerów.
  • Spróbuj wyłączyć kompresję, jeśli struktury danych są nadal złożone.
  • Wypróbuj format pliku MAT v7.3 za pomocą „-v7.3”
  • Jeśli korzystasz z sieciowego systemu plików, rozważ zapisanie i załadowanie do tymczasowego katalogu na szybkim dysku lokalnym oraz skopiowanie do/z sieci

W przypadku dużych struktur danych szybkość operacji we/wy pliku MAT może być bardziej określona przez wewnętrzną strukturę danych, które zapisujesz, niż przez sam rozmiar wynikowego pliku MAT. (Z mojego doświadczenia wynika, że ​​jest to zwykle główny czynnik w powolnych plikach MAT.) Kiedy mówisz „dowolna struktura Matlab”, sugeruje to, że możesz używać komórek, struktur lub obiektów do tworzenia złożonych struktur danych. Spowalnia to operacje we/wy MAT, ponieważ w plikach we/wy pliku MAT występuje narzut przypadający na jedną tablicę, a elementy składowe tablic komórek i struktur (typy kontenerów) są liczone jako oddzielne tablice. Na przykład 5000 ciągów przechowywanych w cellstr jest znacznie wolniejszych niż te same 5000 ciągów przechowywanych w tablicy znaków 2-D. A przedmioty mają jeszcze więcej nad głową. W ramach testu spróbuj napisać plik o wielkości 1 GB, który zawiera tylko 1 GB prymitywną tablicę losowych uint8 i zobacz, jak długo to potrwa. Stamtąd sprawdź, czy możesz uprościć dane, aby zmniejszyć całkowitą liczbę mxarray, nawet jeśli oznacza to przekształcenie ich w celu serializacji. (Moje doświadczenia z tym dotyczą głównie formatu v7; nowszy format HDF5 może mieć mniejszy narzut na element).

Jeśli twoje pliki danych znajdują się w sieci, możesz również spróbować wykonać operacje zapisywania i ładowania plików tymczasowych na szybkich dyskach lokalnych i oddzielnie używać operacji kopiowania do przenoszenia ich tam iz powrotem między siecią. Przynajmniej w sieciach Windows widziałem przyspieszenie do 2x od tego. Prawdopodobnie z powodu optymalizacji operacja kopiowania pełnego pliku może zrobić, czego nie może zrobić kod MAT I/O.

Wymyślenie alternatywnego formatu pliku, który obsługiwałby w pełni dowolne struktury danych Matlaba i byłby przenośny do innych języków, wymagałoby prawdopodobnie znacznego wysiłku. Spróbuję najpierw wprowadzić mniejsze zmiany dotyczące korzystania z istniejącego formatu.

18
Andrew Janke 26 wrzesień 2012, 10:44

Format mat zmienił się wraz z wersjami Matlaba. Wersja 7.3 używa formatu HDF5, który ma wbudowaną kompresję i inne funkcje, a odczyt/zapis może zająć dużo czasu. Możesz jednak zmusić Matlab do używania poprzednich formatów, które są szybsze (ale mogą zająć więcej miejsca).

Spójrz tutaj:

http://www.mathworks.com/help/matlab/import_export/mat-file-versions.html

3
Bitwise 26 wrzesień 2012, 05:16