Zbyt dużo małych obiektów

Thread View: pl.comp.lang.java

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Borneq Thu, 17 Nov 2011 07:06

#153138

Author: Borneq
Date: Thu, 17 Nov 2011 07:06

9 lines
1525 bytes

Mam graf gdzie są węzły i połączenia jednostronne do innych węzłów. 
Jedno takie połączenie, krawędź to wskaźnik plus label, np 1 bajt, może 
być większy choć i tak warto by wyrównać wskaźnik+label do ośmiu bajtów.
Mam różną liczbę połączeń, może być zero, może np. pięć.
W jeżykach gdzie są struktury, można by zrobić taką tablicę 5*8 bajtów 
rozszerzaną w miarę potrzeb. Jedna klasa obsługiwała by węzły, zawierała 
by wskaźnik na tablicę struktur. Gdy nie ma struktur, muszę mieć listę i 
przydzielać pamięć dla każdego 8-bajtowego obiektu. Czy da się coś 
zrobić aby mieć coś w rodzaju tablicy struktur?

Re: Zbyt dużo małych obiektów

#153139

Author: jolz
Date: Thu, 17 Nov 2011 18:51

7 lines
1410 bytes

Tablica bajtow + kod ktory je dodaje i odczytuje odpowiednio 
interpretujac. Czyli zawsze dodaje/zmienia/usuwa po 8 bajtow i wie ktore 
bajty to wskaznik a ktore to label. Troche wiecej roboty niz z gotowa 
struktura, ale kodu niewiele do napisania.
Jak mi sie grafy nie miescily w ktorejs z javovych biblitek do grafow to 
wystarczylo stworzyc wlasne grafy wykorzystujac kolekcje operujace na 
prymitywach (chyba fastutil).

Re: Zbyt dużo małych obiektów

#153140

Author: Jacek Czerwinski
Date: Thu, 17 Nov 2011 19:08

19 lines
1832 bytes

W dniu 2011-11-17 08:06, Borneq pisze:
> W jeżykach gdzie są struktury,

Dalekie skojarzenie.

Popularne API, np. List, Set itp to czasem w rzeczywistości interfejsy 
(myslowo sobie przedstawmy, na potrzeby tego wątku, jako klasy o 
rozmiarze danych równym zero). Mają czasem bardzo ciekawe implementacje, 
np. EnumSet<E> który spełnia całe wymagane API ale nie ciągnie więcej 
pamięci niż jeden long/niewielka ilość long'ów), bo jest 
zaimplementowany jako stara dobra maska bitowa. Pouczający jest jego 
"konstruktor", dość dziwny, ale właśnie domyślam się, o tę pamięć chodzi.

To trochę łatwiej mentalnie złapać (przynajmniej mi), jak się przyjmie 
javowskie patrzenie na obiekt jako 'funkcjonalność' a porzuci C++ jako 
'obszar pamięci (znów, chore szkolne skojarzenie, że obszar ciągły) i 
metody na tym wykonywane'. Mogą wyjść fajne skutki takiej zmiany myślenia.

Nie wiem, jak to się przenosi na patrzenie na Twój problem.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads