Misterna i wyrafinowana struktura poszyta wskaźnikami została utworzona w pamięci, a
teraz trzeba ją zapisać na dysku - tak, żeby się przy wczytywaniu jak najszybciej
odtworzyła w stanie "operacyjnym".
Jakieś równie wyrafinowane pomysły? :-)

do góry

On 24/07/2019 19:25, DMR wrote:
> Misterna i wyrafinowana struktura poszyta wskaźnikami została utworzona w pamięci,
a teraz trzeba ją zapisać na dysku - tak, żeby się przy wczytywaniu jak najszybciej
odtworzyła w stanie "operacyjnym".
> Jakieś równie wyrafinowane pomysły? :-)

Może taki: wybierz sobie jakiś adres z przepastnej przestrzeni 64bit i
zarezerwuj go systemowo. Potem zrób allokator przydzielający obiekty
tylko w tym rejonie.

Zapis i odczyt staje się wtedy trywialny.

Bardziej wyrafinowany: napisz własny offset_ptr<> który zamiast
wskaźnika w środku trzyma offset od jakiejś statycznej zmiennej bazowej
i przelicza je w czasie rzeczywistym na wskaźniki podczas wołania.

do góry

On 2019-07-24 19:25, DMR wrote:
> Misterna i wyrafinowana struktura poszyta wskaźnikami została utworzona w pamięci,
a teraz trzeba ją zapisać na dysku - tak, żeby się przy wczytywaniu jak najszybciej
odtworzyła w stanie "operacyjnym".
> Jakieś równie wyrafinowane pomysły? :-)

Jaki język prog.?

AK

do góry

> Jaki język prog.?

"struktura poszyta wskaźnikami" :-)

C/C++, ale nie o lingwistykę tu biega, tylko raczej o ogólną rozkminę tematu.
Kolega wyżej zasugerował coś w ten deseń - można podziałać w apriorycznie
zaalokowanym bloku pamięci, a potem przeliczyć offsety wskaźników względem punktu
wejścia.
Ma to sens?
Czy wypocina straszna?

do góry

On 24/07/2019 21:58, DMR wrote:
> Kolega wyżej zasugerował coś w ten deseń - można podziałać w apriorycznie
zaalokowanym bloku pamięci, a potem przeliczyć offsety wskaźników względem punktu
wejścia.

Nie, żadnego liczenia offsetów. offset_ptr<> zawiera już poprawny
offset, bez względu na to gdzie zostanie całośc załadowana. Taka
struktura wymaga tylko załadowania pooola pamięci z dysku i odtworzenia
*jednej* zmiennej globalnej która jest jedyną zmieniającą się wartością
wskazującą na bufor allokatora, poola czy czegoś innego do zarządzania
pamięcią.

Można to rozwijać dalej, np. offsety są zależne od typu i każdy typ ma
własny allokator ładowany w dowolne miejsce pamięci aby oszczędzić
fragmentację.

Jednak czasy 32 bitów pamięci wirtualnej słusznie mineły.

> Ma to sens?
> Czy wypocina straszna?

Takie sztuczki używałem kiedyś m.in. w kompaktującym allokatorze pamięci
na mikrokontrolerze. Opakowane w jakiś smart_ptr<> powodowało że cała i
skomplikowana abstrakcja była przezroczysta.

do góry

On 2019-07-24 21:58, DMR wrote:
>> Jaki język prog.?
>
> "struktura poszyta wskaźnikami" :-)
>
> C/C++, ale nie o lingwistykę tu biega, tylko raczej o ogólną rozkminę tematu.
> Kolega wyżej zasugerował coś w ten deseń - można podziałać w apriorycznie
zaalokowanym bloku pamięci, a potem przeliczyć offsety wskaźników względem punktu
wejścia.
> Ma to sens?
> Czy wypocina straszna?

Czy straszna to nie wiem (IMHO nie calkiem), ale jednak w pewnym sensie
"wypocina".
Do takich celow sluza obiektowe/drzewiaste/grafowe bazy danych.
Np. ObjectDB w Javie, a w C++ np. ObjectStore czy inny Versant.

PS: dlatego spytalem o jezyk.

AK

do góry

Ja tam jestem amator, a więc jako osobnik nieprzewidywalny mogę w ogóle nie wiedzieć,
że się "normalnie" nie da... ;-)



> Czy straszna to nie wiem (IMHO nie calkiem),
> ale jednak w pewnym sensie "wypocina".


Logika podpowiada, że skoro dane na dysku są jednym "klockiem", to jeśli podobnie
zorganizuje się je w pamięci, powinno to zadziałać najsprawniej.
Pozostaje wtedy tylko przeliczyć offsety wskaźników na zero przy zapisie i względem
początku zaalokowanego obszaru przy odczycie.
Prościej się chyba nie da. :-)
Ewentualnie można by zapisywać węzły w "odpowiedniej" kolejności - ale to na pierwszy
rzut oka trywialne zadanie, wcale takim nie jest. Przynajmniej ja się poddałem.

Mam taką strukturę, którą tworzy się tylko raz, żeby jej potem wielokrotnie używać -
koncepcja sortowania/porządkowania danych i budowania na nowo drzewa za każdym
odczytem, jakoś mnie tak uwiera...

do góry

On 26/07/2019 22:09, DMR wrote:
> Pozostaje wtedy tylko przeliczyć offsety wskaźników na zero przy zapisie

Czyli serializacja bo zmieniasz dane w locie. Czyli nie tak jak chciałeś
w pierwszym mailu, czyli szybko.

> Prościej się chyba nie da. :-)

Da się. Pytanie na ile to krytyczne aby było naprawdę szybko bo idę o
zakład że nie ma to żadnego znaczenia praktycznego.

do góry

On 2019-07-26 22:09, DMR wrote:
> Logika podpowiada, że skoro dane na dysku są jednym "klockiem", to jeśli podobnie
zorganizuje
się je w pamięci, powinno to zadziałać najsprawniej.

No ale co np, z transakcjami itp?.
"Nie wiem , nie znam sie,zarobiony jestem", no ale wiem ze
np. Perst czy McObject do Javy maja "wbudowana" oblugę spartial data,
w szczegolnosci indeksy do kd-tree.
ObjectStore zapewne tez, bo przeciez *.dwg AutoCADa to tak naprawde
ObjectDatabase "zapewne" przystosowane do problemu najblizszego
sasiedstwa...

PS: Sorry, ale zajmowalem sie CADami "wieki temu".
PS1: Do ogolnego/grafowego repo polecam OrientDB.
Jak dla mnie rewalka w segmencie OpenSource.

PS1: Tak tak.. SQL/table_relations to nie wszystko/dla mnie nie top.
Graph/tree databases to wcale nie tylko sredniowiecze (Ingres).

AK

do góry

On 2019-07-26 22:33, heby wrote:
> Da się. Pytanie na ile to krytyczne aby było naprawdę szybko bo idę o
> zakład że nie ma to żadnego znaczenia praktycznego.

Tez tak sądze/twierdzę. Wczytywanie z dysku w spodziewanycm "kontekscie"
malo znaczy.
Duzo znaczy to co sie dzieje pozniej w pamieci, czyli
znajdowanie najblizszych (i niekoniecznie niepijących) sąsiadów :)

AK

do góry