Wydajność klasy vector

Wydajność klasy vector
ZK
  • Rejestracja:prawie 7 lat
  • Ostatnio:6 miesięcy
  • Postów:273
0

Zajmuje się głownie programowaniem w C# . Szczegółowo zacząłem studiować C++ od niedawna
W jednej z książek wyczytałem, że funkcja push_back klasy vector świetnie nadaje się do wczytywania danych z dysku bajt po bajcie..
Mam poważne **wątpliwości odnośnie wydajności **bo wiem jak to jest zrobione w klasie List<T> na platformie NET. Przeglądałem też pobieżnie kody źródłowe klasy VECTOR
Czy ktoś wie więcej na ten temat ?

edytowany 1x, ostatnio: Zimny Krawiec
kq
Moderator C/C++
  • Rejestracja:prawie 12 lat
  • Ostatnio:dzień
  • Lokalizacja:Szczecin
2

Jakież to wątpliwości masz?


koszalek-opalek
  • Rejestracja:około 9 lat
  • Ostatnio:ponad 2 lata
2

@Zimny Krawiec: No ale vector jest całkiem inaczej skonstruowany niż List. Weź dokumentacje i zobacz jakie są wytyczne co do wydajności różnych operacji:
https://en.cppreference.com/w/cpp/container/vector/push_back
No i możesz sam zrobić trochę benchmarków, to się przekonasz...

PS. Ale w ogóle wczytywanie po bajcie to nie wiem czy jest najlepszy pomysł... Choć pewnie bufory biblioteczne i systemowe pomogą.

ZK
  • Rejestracja:prawie 7 lat
  • Ostatnio:6 miesięcy
  • Postów:273
0

@kq: Ja sobie to tak wyobrażam że niezależnie od języka miejsce w którym są przechowywane dane musi być jakimś ciągłym obszarem pamięci a nie luźno rozsypanymi danymi jak na dysku półprzewodnikowym. A skoro tak jest jak ja przypuszczam . To trzeba albo wcześniej zarezerwować jakiś większy obszar pamięci a potem jak zabraknie miejsca trzeba utworzyć nowy większy bufor i dane przepisać. Tak jest na platformie NET.

edytowany 1x, ostatnio: Zimny Krawiec
koszalek-opalek
  • Rejestracja:około 9 lat
  • Ostatnio:ponad 2 lata
1

@Zimny Krawiec: Ale vector ma dane w ciągłym obszarze... Natomiast tak być nie musi, w każdym języku mogą być takie i owakie struktury -- i ciągłe i rozsypane...

edytowany 1x, ostatnio: koszalek-opalek
ZK
  • Rejestracja:prawie 7 lat
  • Ostatnio:6 miesięcy
  • Postów:273
vpiotr
  • Rejestracja:prawie 14 lat
  • Ostatnio:prawie 3 lata
0

Co jest elementem listy?
A) jeden znak
B) jedna linia pliku
C) caly plik

List<T> prawdopodobnie jest odpowiednikiem std::vector, ale nie czytalem zrodel obu...

edytowany 1x, ostatnio: vpiotr
ZK
Typem bazowym klasy List<T> jest oczywiście zwykła tablica bo nie może być inaczej. Elementy tablicy mogą być różnego typu
koszalek-opalek
  • Rejestracja:około 9 lat
  • Ostatnio:ponad 2 lata
1

@Zimny Krawiec: Przeczytałem źródła, wygląda, że są bardzo podobne (przynajmniej Add i push_back), ale spróbuj zrobić benchmarki...

ZK
Nie wiem jak się robi benchmarki ale jakby ktoś zrobił porównanie na jakieś większej ilości danych to byłbym wdzięczny
koszalek-opalek
@Zimny Krawiec: No właśnie tak się roi benchmarki jak napisałeś... :)
vpiotr
Zrob tylko dobrze powtorne inicjowanie struktury bo mozna przy tym wpasc na benchmarkowa mine.
AL
  • Rejestracja:prawie 11 lat
  • Ostatnio:około 3 lata
  • Postów:1493
1

@Zimny Krawiec: jak potrzebujesz żeby to było wydajne to zmierz. Jeśli nie potrzebujesz jeszcze - nie martw się na zapas.
Ale skoro to aż taki problem, to podpowiem, że po coś tam jest metoda reserve ;)

edytowany 1x, ostatnio: alagner
ZK
metoda reserve to brzmi logiczne. Też bym w tym kierunku kombinował
enedil
  • Rejestracja:prawie 12 lat
  • Ostatnio:4 dni
  • Postów:1027
0

Dużo tutaj było powiedziane, ale nadal nie rozumiem jaki jest problem z realokacją co jakiś czas? I tak wielkość alokacji jest podwajana jak braknie miejsca, tym samym powodując że stracisz max 2x pamięci. Przy ciągłych push_backach, koszt czasowy się amortyzuje do stałego. A jeśli zmierzyłeś, że masz potrzebę ominięcia tych realokacji, jak już było zauważone, można użyć reserve (czy też innych, jak chcesz skrócić wektor a nie wydłużyć).

ZK
Ktoś kto czyta tę książkę może odnieść wrażenie że wektor się może rozszerzać o jedną jednostkę po każdym push_backu jakby był z gumy bez żadnych konsekwencji. Tylko o to mi chodziło
enedil
@Zimny Krawiec: a to nie wiem czy są takie gwarancje, ale wszystkie znane mi implementacje nie są aż tak głupie.
Szalony Programista
Szalony Programista
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 4 lata
  • Postów:227
1

Z dysku nie da się wczytać 1 bajta, zawsze wczytuje się jeden sektor 512 bajtów minimum i potem masz abstrakcję, która ci podaje buffor jako formę dysku, ale już w pamięci ram, i z poziomu C po prostu jeśli będziesz chciał więcej niż te 512 to ci doczyta z tego dysku, kolejny sektor.

Ale w C masz seek i możesz sobie ustawić pozycję w buforze od którego bajta ma wczytywać.

Azarien
  • Rejestracja:ponad 21 lat
  • Ostatnio:około 7 godzin
0

Ale jaki w ogóle sens wczytywać dane z dysku "bajt po bajcie"? Jeśli czytamy z dysku pojedyncze bajty i każdy bajt osobno będzie trafiał do vectora za pomocą push_back to to rzeczywiście będzie powolne. Ale tak się nie robi. Jak masz do odczytania N bajtów to przekaż to N do fread czy do ifstream::read i czytaj N bajtów, a nie N razy po bajcie.

enedil
z tego co rozumiem, autor przeczytał o przykładzie push_backa, który oczywiście nie będzie najszybszy, ale przecież nie o to w tym temacie chodzi
ZK
Chodziło o to że nie wiadomo gdzie jest koniec np. tekstu . Kiedy wczytujemy bajt po bajcie np. tekst w ASCII i napotykamy 0 - null dowiadujemy się że jest koniec .
stivens
  • Rejestracja:ponad 8 lat
  • Ostatnio:9 minut
1

W vectorze mozna swoja droga zarezerowac pamiec. Mowimy mu ze pewnie bedzie mial z 1000 elementow (vect.reserve(1000) czy jakos tak) wiec realokacja sie przestaje dziac :)


λλλ
kwalifika
  • Rejestracja:ponad 4 lata
  • Ostatnio:około 4 lata
  • Postów:125
0

już tradycyjnie: należy użyć file mapping zamiast vector, hahaha!

i nie potrzeba żadnej rezerwacji, realokacji, ani nawet demokracji!

edytowany 1x, ostatnio: kwalifika
enedil
No z całym szacunkiem, to zależy od zastosowania. Zdarza się, że warto użyć normalnego streama/FILE*

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.